[asterisk-bugs] [DAHDI-linux 0013954]: [patch] incoherent handling of span timing and lack of input validation
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Jan 27 20:54:53 CST 2009
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=13954
======================================================================
Reported By: tzafrir
Assigned To: tzafrir
======================================================================
Project: DAHDI-linux
Issue ID: 13954
Category: General
Reproducibility: always
Severity: minor
Priority: normal
Status: confirmed
======================================================================
Date Submitted: 2008-11-23 05:42 CST
Last Modified: 2009-01-27 20:54 CST
======================================================================
Summary: [patch] incoherent handling of span timing and lack
of input validation
Description:
CVE-2008-5744
We connected two units of Astribank 8-port BRI to a system and generated
configuration for that with dahdi_genconf . The generated configuration
includes:
span=1,1,...
span=2,2,...
...
span=15,15,...
span=16,16,...
Sadly dahdi_cfg did not like that last line:
line 20: Timing should be a number from 0 to 15, not '16'
Hmmm... who cares about that number anyway? Isn't it a simple priority?
Weel, not. dahdi-base.c does not use lc->sync . Thus it at the moment has
nothing to do with sync master selection, and only optionally used by
channel drivers.
How do channel drivers use it?
In xpp it is handled by the card_X drivers. In card_bri.c it is ignored.
In card_pri.c it is used for selecting the syncer among the ports of the
same Astribank PRI unit (but any value is valid: the highest wins).
wcte12xp also gives it a clear meaning: either 0 (we provide sync to ther
other side) or anything else (we take sync from the other side).
For wct4xxp valid values seem to be 0-3 . Any value above 4 is considered
as 0. Hence the configuration generated by dahdi_genconf for a system with
two such 4-port cards will be invalid.
So far all drivers have at least validated their input. But now we get to
the good part. wcte11xp.c write the value that they recieve from userspace
to a register:
control_set_reg(wc, WC_CLOCK, 0x06 | wc->sync | clockextra);
I don't have the specs here so I'm not sure what is the actual impact here
of an invalid value.
But the prize goes to tor2.c . It has the code as wct4xp.c , except the
input validation part:
if (lc->sync) {
p->tor->syncs[lc->sync - 1] = span->spanno;
p->tor->psyncs[lc->sync - 1] = p->span + 1;
}
So first those drivers need fixing. Then we need to figure out exactly
what the "timing" parameter means.
Note that this is exploitable by anybody who has write access to
zaptel.conf/system.conf and by anybody who has write access to
/dev/dahdi/ctl . There's almost no good reason why Asterisk would need to
write there. Yet this bug is exploitable by the Asterisk user rather than
merely by root.
Added a patch for tor2 in dahdi. It applies to tor2 in Zaptel. It uses a
different approach than wct4xxp. Which approach do you prefer?
======================================================================
----------------------------------------------------------------------
(0098925) svnbot (reporter) - 2009-01-27 20:54
http://bugs.digium.com/view.php?id=13954#c98925
----------------------------------------------------------------------
Repository: dahdi
Revision: 5865
_U linux/tags/2.1.0.4/
U linux/tags/2.1.0.4/drivers/dahdi/dahdi-base.c
U linux/tags/2.1.0.4/drivers/dahdi/dahdi_dynamic.c
U linux/tags/2.1.0.4/drivers/dahdi/tor2.c
U linux/tags/2.1.0.4/drivers/dahdi/wct1xxp.c
U linux/tags/2.1.0.4/drivers/dahdi/wct4xxp/base.c
U linux/tags/2.1.0.4/drivers/dahdi/wcte11xp.c
U linux/tags/2.1.0.4/drivers/dahdi/wcte12xp/base.c
U linux/tags/2.1.0.4/include/dahdi/kernel.h
------------------------------------------------------------------------
r5865 | sruffell | 2009-01-27 20:54:51 -0600 (Tue, 27 Jan 2009) | 28 lines
Merged revisions 5590,5811,5819 via svnmerge from
https://origsvn.digium.com/svn/dahdi/linux/trunk
........
r5590 | tzafrir | 2008-12-19 04:39:31 -0800 (Fri, 19 Dec 2008) | 4 lines
Fix the safety check in tor2 to be for SPANS_PER_CARD
Thanks to Eugene Teo, in a from issue http://bugs.digium.com/view.php?id=13954 .
........
r5811 | sruffell | 2009-01-25 23:19:47 -0800 (Sun, 25 Jan 2009) | 7 lines
Ensure the channel is in a good state before placing it on the chans
arrays.
Also ensure that dahdi_receive holds the chan_lock while iterating over
the
chans array to prevent channels from entering or leaving the array while
the
interrupt handler is running.
Related to issue http://bugs.digium.com/view.php?id=14183 .
........
r5819 | sruffell | 2009-01-26 11:44:36 -0800 (Mon, 26 Jan 2009) | 3 lines
Manipulate the REGISTERED flag with atomic bitops now since the bit is set
outside the protection of any locks.
........
------------------------------------------------------------------------
http://svn.digium.com/view/dahdi?view=rev&revision=5865
Issue History
Date Modified Username Field Change
======================================================================
2009-01-27 20:54 svnbot Checkin
2009-01-27 20:54 svnbot Note Added: 0098925
======================================================================
More information about the asterisk-bugs
mailing list