[Home]

Summary:ASTERISK-09772: IAX2 protocol flaw in IC_NEW could cause reflective amplification DoS
Reporter:Joel R. Voss (javantea)Labels:
Date Opened:2007-06-27 16:52:29Date Closed:2008-04-22 18:31:20
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_iax2
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) iax_dcallno_check.rev9.txt
( 1) iax_dcallno_check-1.2.rev3.txt
Description:The IAX2 protocol allows an IC_NEW packet to start a call. This is a udp packet that is only 18 bytes long. A call can be quite long and contains a lot of data. Specifically my simple answering machine sends 26307 bytes in 723 packets in 32.0032 seconds. That is 6576.75 bits per second. Using uLaw or another higher bitrate codec, this rate can be increased.

Since UDP can be spoofed, it seems possible that an asterisk server can be tricked into sending megabits per second (until it chokes) at a target with a very low cost to the attacker (18 byte udp packet). I have not tested spoofing an address, but I suspect that it will work.

Since this is a protocol flaw and there are hardware implementations that would be broken by changing the protocol, this does not seem to be fixable. If someone with knowledge of these type of issues could discuss this with me, I would be much more confident in this.

I wrote a python implementation of IAX2 protocol to fuzz the IAX2 protocol and I found this by accident in my first test.


****** ADDITIONAL INFORMATION ******

If you have python, gnu-style head, and netcat, you can test this on your own server like this:
python -c "print '\x80\xeb\x00\x00\x00\x00\x00\x07\x00\x00\x06\x01\x08\x04\x00\x00\x02\xaa'" | head -c 18 | nc -u 192.168.0.3 4569
Comments:By: Joel R. Voss (javantea) 2007-06-27 17:00:55

I just noticed that you can do it with echo =).
echo -ne '\x80\xeb\x00\x00\x00\x00\x00\x07\x00\x00\x06\x01\x08\x04\x00\x00\x02\xaa' | nc -u 192.168.0.3 4569

By: Jason Parker (jparker) 2007-06-27 17:40:00

Marking this issue private for now, until we can investigate this.

By: Jason Parker (jparker) 2007-06-28 18:17:24

I read through the RFC (a few times, even), and we had also discussed this very issue at our recent Asterisk Developers Conference with a Security Researcher from IBM ISS, and we determined that it does not appear that this would be an issue.

We do not immediately transmit audio on receipt of a NEW packet.  We first send an ACCEPT, and require an explicit ACK before we will start transmitting any audio.  UDP spoofing to request audio is not possible in this scenario, since you must know the callid which is sent in the ACCEPT message and send it in an ACK message.

You may get several extra bytes back (I believe the responses you are seeing are the ACCEPT messages).  For various reasons, this is not something that would be useful to "exploit".

Also, you specified that you are running Asterisk 1.2.13 - please upgrade, there have been other security issues that have been solved since that version.


Unless you have any additional comments or concerns, I will be closing this issue tomorrow, for the reasons stated above.

By: Joel R. Voss (javantea) 2007-06-28 18:41:20

Hello qwell,

Thank you for the prompt and well-thought response. It is very nice to meet a smart security + developer. I am fairly confident that your conclusion is wrong. Last night my friend widge tested it on 1.4.3 and it worked. Asterisk 1.4.3 sends audio right upon receiving the IC_NEW. The protocol may ask for ACCEPT and ACK (which would be a good solution) but Asterisk does not require ACCEPT or ACK. If hard phones are using this functionality, fixing asterisk will break the phones. You can test this using tcpdump and that echo command in the first note. I'll test it on 1.4.5 tonight if I'm not swamped with work. If you don't have a asterisk box to test (I'd be surprised), you may try my box (suzy.altsci.com).

I'm a security researcher, so my interest in working on 1.2.13 is to test the bug in FT_TEXT. I'll be writing an exploit for that vulnerability next month as well as the buffer overflow in FT_VIDEO.
http://www.securiteam.com/securitynews/5NP0820LFY.html
http://www.securiteam.com/unixfocus/5EP0B1FIUU.html

Also, I'm having issues with zaptel and 1.4, so I can't use zaptel in 1.4 yet.

Regards,
Joel R. Voss

By: Tilghman Lesher (tilghman) 2007-06-29 00:28:43

This should be somewhat close to a fix.  I'll test it out in the morning.

By: Russell Bryant (russell) 2007-06-29 10:40:01

Asterisk 1.4.3 probably did.  However, it has been fixed since then.  Specifically, see the commit to Asterisk 1.4 in revision 65679.

Also, for older versions, it is worth noting that people are only vulnerable to this if they accept unauthenticated IAX2 calls.

I wouldn't consider this a protocol bug, since any implementations can do what we have done, which is to not begin sending any audio until we get a response to our ACCEPT.

By: Russell Bryant (russell) 2007-06-29 11:16:55

I have now backported the changes that we made in 1.4 and trunk to 1.2 to ensure that a 3-way handshake is completed before beginning to send audio.  revision 72630

By: Russell Bryant (russell) 2007-06-29 11:24:14

Given that the latest versions of all of our code now no longer has this issue, I think we can mark this as closed.  Thanks for the feedback.

By: Joel R. Voss (javantea) 2008-04-18 03:09:51

You added a requirement for an IC_ACK after the IC_ACCEPT which is a handshake, but a malicious user can still spoof the IC_ACK as easily as the IC_NEW which turns this one packet 18 byte attack into a two packet 30 byte attack. I have a pair of echos that recreate this, but since I am releasing my exploit framework publicly now, I thought I would send a link to it.
https://www.altsci.com/concepts/page.php?s=asteri&p=2

I will be speaking at Toorcon Seattle 2008 about this issue.
http://seattle.toorcon.org/2008/conference.php?id=12

I was able to cause asterisk to send 8Mbps for 30+ seconds today using this attack without causing any harm to the system. The cost to the attacker is 30kB. This is a 1000:1 amplification.

By: Digium Subversion (svnbot) 2008-04-22 17:08:55

Repository: asterisk
Revision: 114557

U   tags/1.4.19.1/channels/chan_iax2.c

------------------------------------------------------------------------
r114557 | russell | 2008-04-22 17:08:54 -0500 (Tue, 22 Apr 2008) | 5 lines

When we receive a full frame that is supposed to contain our call number,
ensure that it has the correct one.
(closes issue ASTERISK-9772)
(AST-2008-006)

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

http://svn.digium.com/view/asterisk?view=rev&revision=114557

By: Digium Subversion (svnbot) 2008-04-22 17:10:19

Repository: asterisk
Revision: 114558

U   branches/1.4/channels/chan_iax2.c

------------------------------------------------------------------------
r114558 | russell | 2008-04-22 17:10:19 -0500 (Tue, 22 Apr 2008) | 5 lines

When we receive a full frame that is supposed to contain our call number,
ensure that it has the correct one.
(closes issue ASTERISK-9772)
(AST-2008-006)

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

http://svn.digium.com/view/asterisk?view=rev&revision=114558

By: Digium Subversion (svnbot) 2008-04-22 17:12:18

Repository: asterisk
Revision: 114559

_U  trunk/
U   trunk/channels/chan_iax2.c

------------------------------------------------------------------------
r114559 | russell | 2008-04-22 17:12:17 -0500 (Tue, 22 Apr 2008) | 13 lines

Merged revisions 114558 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114558 | russell | 2008-04-22 17:15:36 -0500 (Tue, 22 Apr 2008) | 5 lines

When we receive a full frame that is supposed to contain our call number,
ensure that it has the correct one.
(closes issue ASTERISK-9772)
(AST-2008-006)

........

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

http://svn.digium.com/view/asterisk?view=rev&revision=114559

By: Digium Subversion (svnbot) 2008-04-22 17:13:44

Repository: asterisk
Revision: 114560

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_iax2.c

------------------------------------------------------------------------
r114560 | russell | 2008-04-22 17:13:43 -0500 (Tue, 22 Apr 2008) | 21 lines

Merged revisions 114559 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r114559 | russell | 2008-04-22 17:17:31 -0500 (Tue, 22 Apr 2008) | 13 lines

Merged revisions 114558 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114558 | russell | 2008-04-22 17:15:36 -0500 (Tue, 22 Apr 2008) | 5 lines

When we receive a full frame that is supposed to contain our call number,
ensure that it has the correct one.
(closes issue ASTERISK-9772)
(AST-2008-006)

........

................

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

http://svn.digium.com/view/asterisk?view=rev&revision=114560

By: Digium Subversion (svnbot) 2008-04-22 17:15:27

Repository: asterisk
Revision: 114561

U   branches/1.2/channels/chan_iax2.c

------------------------------------------------------------------------
r114561 | russell | 2008-04-22 17:15:26 -0500 (Tue, 22 Apr 2008) | 5 lines

When we receive a full frame that is supposed to contain our call number,
ensure that it has the correct one.
(closes issue ASTERISK-9772)
(AST-2008-006)

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

http://svn.digium.com/view/asterisk?view=rev&revision=114561

By: Digium Subversion (svnbot) 2008-04-22 18:31:20

Repository: asterisk
Revision: 114570

_U  team/seanbright/resolve-shadow-warnings/
U   team/seanbright/resolve-shadow-warnings/apps/app_queue.c
U   team/seanbright/resolve-shadow-warnings/channels/chan_iax2.c
U   team/seanbright/resolve-shadow-warnings/include/asterisk/pbx.h
U   team/seanbright/resolve-shadow-warnings/main/channel.c
U   team/seanbright/resolve-shadow-warnings/main/pbx.c

------------------------------------------------------------------------
r114570 | seanbright | 2008-04-22 18:31:18 -0500 (Tue, 22 Apr 2008) | 113 lines

Merged revisions 114538,114540,114543,114546,114548,114551,114553,114559 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r114538 | russell | 2008-04-22 14:04:39 -0400 (Tue, 22 Apr 2008) | 17 lines

Merged revisions 114537 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114537 | russell | 2008-04-22 13:03:33 -0500 (Tue, 22 Apr 2008) | 9 lines

If the dial string passed to the call channel callback does not indicate an
extension, then consider the extension on the channel before falling back
to the default.

(closes issue ASTERISK-11881)
Reported by: darren1713
Patches:
     exten_dial_fix_chan_iax2.c.patch uploaded by darren1713 (license 116)

........

................
r114540 | qwell | 2008-04-22 14:14:09 -0400 (Tue, 22 Apr 2008) | 8 lines

Allow setqueuevar=yes (et al) to work, after changes to pbx_builtin_setvar()

(closes issue ASTERISK-11888)
Reported by: bcnit
Patches:
     12490-queuevars-3.diff uploaded by qwell (license 4)
Tested by: qwell

................
r114543 | russell | 2008-04-22 14:30:47 -0400 (Tue, 22 Apr 2008) | 10 lines

Blocked revisions 114542 via svnmerge

........
r114542 | russell | 2008-04-22 13:29:56 -0500 (Tue, 22 Apr 2008) | 3 lines

After a parked call times out, allow the call back to the parker to time out.
(closes issue ASTERISK-10449)

........

................
r114546 | russell | 2008-04-22 15:45:12 -0400 (Tue, 22 Apr 2008) | 9 lines

Blocked revisions 114545 via svnmerge

........
r114545 | russell | 2008-04-22 14:45:00 -0500 (Tue, 22 Apr 2008) | 2 lines

Trivial change to read the number of samples from a frame before calling ast_write()

........

................
r114548 | russell | 2008-04-22 16:25:56 -0400 (Tue, 22 Apr 2008) | 2 lines

re-add a fix that got lost with a recent change

................
r114551 | russell | 2008-04-22 17:15:41 -0400 (Tue, 22 Apr 2008) | 11 lines

Blocked revisions 114550 via svnmerge

........
r114550 | russell | 2008-04-22 16:14:55 -0500 (Tue, 22 Apr 2008) | 4 lines

I thought I was going to be able to leave 1.4 alone, but that was not the case.
I ran into some problems with G.722 in 1.4, so I have merged in all of the fixes
in this area that I have made in trunk/1.6.0, and things are happy again.

........

................
r114553 | murf | 2008-04-22 17:57:57 -0400 (Tue, 22 Apr 2008) | 14 lines


(closes issue ASTERISK-11872)
Reported by: triccyx

I had a bit a problem reproducing this in my setup (trying not to disturb my other stuff)
but finally, I got it. The problem appears to be that the extension is being added in
replace mode, which kinda assumes that the pattern trie has been formed, when in fact,
in this case, it was not. The checks being done are not nec. when the tree is not yet
formed, as changes like this will be summarized when the trie is formed in the future.

I tested the fix, and the crash no longer happens. Feel free to open the bug again if
this fix doesn't cure the problem.


................
r114559 | russell | 2008-04-22 18:17:31 -0400 (Tue, 22 Apr 2008) | 13 lines

Merged revisions 114558 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r114558 | russell | 2008-04-22 17:15:36 -0500 (Tue, 22 Apr 2008) | 5 lines

When we receive a full frame that is supposed to contain our call number,
ensure that it has the correct one.
(closes issue ASTERISK-9772)
(AST-2008-006)

........

................

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

http://svn.digium.com/view/asterisk?view=rev&revision=114570