Bugzilla Bug 171467

Should be fixed in 1.2.17 and 1.4.2, to be released later today. According to
the dates patches seems to be already in SVN.

MADYNES Security Advisory 

 <http://madynes.loria.fr/> http://madynes.loria.fr 

Title: Asterisk SIP INVITE remote DOS 

Release Date: 
      08/03/2007 
Severity: 
      High - Denial of Service 
Advisory ID:KIPH1 
Software: 
      Asterisk 
       <http://www.asterisk.org/> http://www.asterisk.org/ 

AsteriskR is a complete IP PBX in software. It runs on a wide variety of 
 operating systems including Linux, Mac OS X, OpenBSD, FreeBSD and Sun 
 Solaris and provides all of the features you would expect from a PBX 
 including many advanced features that are often associated with high end 
 (and high cost) proprietary PBXs. AsteriskR supports Voice over IP in many 
 protocols, and can interoperate with almost all standards-based telephony 
 equipment using relatively inexpensive hardware. 

Affected Versions: 
      Asterisk 1.2.14, 1.2.15, 1.2.16 
      Asterisk 1.4.1 
      probably previous versions also 

Unaffected Versions: Trunk version to date (13/03/2007) 

Vulnerability Synopsis: After sending a crafted INVITE message the software 
 finish abruptly its execution with a Segmentation Fault provoking a Denial 
 of Service (DoS) in all the services provided by the entity. 

Impact: A remote individual can remotely crash and perform a Denial of 
 Service(DoS) attack in all the services provided by the software by sending 
 one crafted SIP INVITE message. This is conceptually similar to the "ping of 
 death". 

Resolution: The problem has been fixed in Asterisk versions 1.4.2 and 
 1.2.17, which is released today 19/03/2007 

Vulnerability Description: After sending a crafted message the software 
 crash abruptly. The message in this case is an anonymous INVITE where the 
 SDP contains 2 connection headers. The first one must be valid and the 
 second not where the IP address should be invalid. The callee needs not to 
 be a valid user or dialplan. In case where asterisk is set to disallow 
 anonymous call, a valid user and password should be known, and while 
 responding the corresponding INVITE challenge the information should be 
 crafted as above. After this crafted SIP INVITE message, the affected 
 software crash immediately. 

Proof of Concept Code: available 

Credits: 
      Humberto J. Abdelnur (Ph.D Student) 
      Radu State (Ph.D) 
      Olivier Festor (Ph.D) 
      This vulnerability was identified by the Madynes research team at 
 INRIA 

      Lorraine, using the Madynes VoIP fuzzer. 
       <http://madynes.loria.fr/> http://madynes.loria.fr/ 

Disclosure Distribution: 

      The advisory will be posted on the following websites: 
      1) Asterisk's website 
      2) <http://madynes.loria.fr/> http://madynes.loria.fr website 

      The advisory will be posted to the following mailing lists: 

      1) full-disclosurelists.grok.org.uk 
      2) voipsecvopisa.org

patch in asterisk trunk:
http://svn.digium.com/view/asterisk/trunk/channels/chan_sip.c?r1=58907&r2=59038

asterisk 1.0.12 is also vulnerable but not supported upstream. i will patch in
our cvs shortly.

net-misc/asterisk-1.0.12-r2 with ported patch in cvs as ~x86 and ~ppc.

x86 team: please test and mark stable (or drop me an email and i will do it).

older 1.0.12 version is ~ppc also so nothing to be done there.

asterisk-1.2.x still to be patched.

I just applied the patch from comment#1 to a clean 1.2.16 and 1.4.1, it did not
change anything. Asterisk still keeps crashing upon reception of such a hand
crafted INVITE. 

I can't imagine how this patch should affect the behavior, because as I see it
(with my small knowledge of C), code is inserted at a position where replies
are handled. The bug must be somwhere in the process_sdp function, not in the
handle_request function.

Created an attachment (id=113848) [details]
Patch for chan_sip to avoid crashing

Further reading of the svn changelog brought me to this diff:

http://svn.digium.com/view/asterisk/trunk/channels/chan_sip.c?r1=58241&r2=58592

That seems to work here. After applying the patch Asterisk returns 488 instead
of crashing. 

I'll attach patches for asterisk 1.2.16 and 1.4.1 here. The 1.2.16 vanilla
patch should work for the 1.2.14 gentoo version, too.

Created an attachment (id=113849) [details]
Patch for chan_sip of Asterisk 1.4.1 to avoid crashing

Created an attachment (id=113851) [details]
chan_sip Patch for Asterisk 1.4.1

Sorry, wrong patch format first...

Add the patch posted in comment#1, too, because this prevents asterisk from
crashing when receiving a return code 0. So different problem, but better to
have a fix for it, too. :)

asterisk-1.2.14-r2 in, tested on my hardened x86 server and sparc stable.

x86 done :)

Thx everyone.

This one is ready for GLSA.

GLSA drafted and ready for review.

Note that upstream has still not released a fixed version.

Sorry for the spam.

New upstream version is available for download. Unfortunately it seems without
much information about the DoS and still no official announcement.

comment #4 is correct. hang on to the glsa for a bit until i can check 1.0.12
for that patch as well.

Back to ebuild status waiting a fixed ebuild for 1.0.x.

i looked through the asterisk 1.0.12 source. the call to ast_gethostbyname in
process_sdp is properly checked upon return. the patch to 1.2/1.4
<http://svn.digium.com/view/asterisk/trunk/channels/chan_sip.c?r1=58241&r2=58592>
adds returns in process_sdp if ast_gethostbyname fails. looks like the
additional, unchecked calls to ast_gethostbyname were added to chan_sip.c in
1.2.

so asterisk 1.0.12 is not vulnerable to the bug described above since it does
not have the code to handle additional media types.

however i did patch it for <http://bugs.digium.com/view.php?id=9313> in
asterisk-1.0.12-r2, but this is just a precaution. i tried to get it to crash
without the fix but could not.

for the glsa, there is no need to list the 1.0.x branch. but please do note in
the GLSA that there are two remote SIP DoS vulnerabilities in 1.2.x (and
1.4.x), <http://bugs.digium.com/view.php?id=9313> and
<http://voipsa.org/pipermail/voipsec_voipsa.org/2007-March/002275.html>.

Thx for the info Rajiv. I've updated the GLSA draft to reflect that this
appears only to affected 1.2+.

Security please review.

The SIP return code 0 issue is described here:
http://bugs.digium.com/view.php?id=9313

CVEs assigned:
The SDP issue: CVE-2007-1561.
The return code 0 issue: CVE-2007-1594

I'm resetting to ebuild status as the return code 0 issues seems to be still
open. VOIP please advise.

(In reply to comment #19)
> The SDP issue: CVE-2007-1561.
> The return code 0 issue: CVE-2007-1594

gustavoz patched both of these in asterisk-1.2.14-r2. asterisk-1.0.12-r2 is not
vulnerable to the first and i patched it for the second. i say ready for GLSA.

voip, upstream bug 9313 is still open, do we have the complete fix and is ready
for GLSA release?

Looks like the patch from comment#1 did not work as expected. I don't have a
test environment usable for testing this issue. I guess, this problem shouldn't
be mentioned in the GLSA. The double sdp vulnerability is fixed, though.

upstream bug is now closed, so i think this is ready for GLSA. Setting to
[glsa] status.

Thx everyone.

GLSA 200704-01