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
Title: Asterisk SIP INVITE remote DOS
High - Denial of Service
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.
Asterisk 1.2.14, 1.2.15, 1.2.16
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
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
Humberto J. Abdelnur (Ph.D Student)
Radu State (Ph.D)
Olivier Festor (Ph.D)
This vulnerability was identified by the Madynes research team at
Lorraine, using the Madynes VoIP fuzzer.
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:
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 attachment 113848 [details, diff]
Patch for chan_sip to avoid crashing
Further reading of the svn changelog brought me to this diff:
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 attachment 113849 [details, diff]
Patch for chan_sip of Asterisk 1.4.1 to avoid crashing
Created attachment 113851 [details, diff]
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 :)
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
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.