|
|
|
|
| |
Credit:
The information has been provided by Mu Security.
The original article can be found at: http://labs.musecurity.com/advisories/MU-200803-01.txt
|
| |
Vulnerable Systems:
* Asterisk version 1.4.18.0 and prior
Immune Systems:
* Asterisk version 1.4.18.1
1) Sending an invalid RTP payload type number in the SDP payload of an INVITE message can cause a write to an invalid memory location. An attacker would have some control over the memory location.
The invalid memory write is in ast_rtp_unset_m_type() (main/rtp.c, line 1655) called by process_line() (channels/chan_sip.c, line 5275). ast_rtp_unset_mt_type() does not validate pt, while it is validated in ast_rtp_set_mt_type() (line 1642). The attacker controls pt and could write a 0 to a wide range of memory locations.
Example invalid SDP payload (invalid RTP payload type is 780903144):
v=0
o=- 817933771 817933775 IN IP4 10.10.1.101
s=session-name
c=IN IP4 10.10.1.101
t=0 0
m=audio 5000 RTP/AVP 0
a=rtpmap:780903144 PCMU/8000
a=rtpmap:4 G723/8000/1
a=rtpmap:97 telephone-event/8000
2) Sending more than 32 RTP payload type number attributes in the SDP payload of a SIP INVITE will overflow a buffer on the stack. An attacker would have some control over the values written.
In process_sdp() (channels/chan_sip.c, line 4980), rtpmap codecs are stored in found_rtpmap_codecs, an array of 32 ints. The number of codecs in the map is stored in last_rtpmap_codec. Codecs are appeneded to the array without checking the size of the array (line 5258). Up to 64 (SIP_MAX_LINES). An attacker would have some control over the values written - the codec must be between 0 and 256 (MAX_RTP_PT).
Example SDP payload:
v=0
o=- 817933771 817933775 IN IP4 10.10.1.101
s=session-name
c=IN IP4 10.10.1.101
t=0 0
m=audio 5000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
[... repeat this line ...]
a=rtpmap:4 G723/8000/1
a=rtpmap:97 telephone-event/8000
Vendor Response / Solution:
Fixed in Asterisk 1.4.18.1 and other branches. Available from http://www.asterisk.org
History:
March 11, 2008 - First contact with vendor
March 18, 2008 - Vendor releases fix and advisory
CVE Information:
CVE-2008-1289
|
|
|
|
|
