[UNIX] IAX2 Channel Driver Resource Exhaustion Vulnerability

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -

IAX2 Channel Driver Resource Exhaustion Vulnerability
------------------------------------------------------------------------

SUMMARY

The IAX2 channel driver in Asterisk is vulnerable to a Denial of Service
attack when configured to allow unauthenticated calls. An attacker can
send a flood of NEW packets for valid extensions to the server to initiate
calls as the unauthenticated user. This will cause resources on the
Asterisk system to get allocated that will never go away. Furthermore, the
IAX2 channel driver will be stuck trying to reschedule retransmissions for
each of these fake calls forever. This can very quickly bring down a
system and the only way to recover is to restart Asterisk.

DETAILS

Vulnerable Systems:
* Asterisk Open Source versions 1.2.20, 1.2.21, 1.2.21.1, and 1.2.22
* Asterisk Open Source versions 1.4.5, 1.4.6, 1.4.7, 1.4.7.1, and 1.4.8
* AsteriskNOW pre-release beta6
* Asterisk Appliance Developer Kit version 0.5.0
* s800i (Asterisk Appliance) version 1.0.0-beta5 up to and including
1.0.2

Immune Systems:
* Asterisk Open Source version 1.2.23 and version 1.4.9
* AsteriskNOW Beta6
* Asterisk Appliance Developer Kit version 0.6.0
* s800i (Asterisk Appliance) version 1.0.3

Within the last few months, Digium made some changes to chan_iax2 to
combat the abuse of this module for traffic amplification attacks.
Unfortunately, this has caused an unintended side effect.

The summary of the change to combat traffic amplification is this. Once
you start the PBX on the Asterisk channel, it will begin receiving frames
to be sent back out to the network. Digium delayed this from happening
until a 3-way handshake has occurred to help ensure that we are talking to
the IP address the messages appear to be coming from. When chan_iax2
accepts an unauthenticated call, it immediately creates the ast_channel
for the call. However, since the 3-way handshake has not been completed,
the PBX is not started on this channel.

Later, when the maximum number of retries have been exceeded on responses
to this NEW, the code tries to hang up the call. Now, it has 2 ways to do
this, depending on if there is an ast_channel related to this IAX2 session
or not. If there is no channel, then it can just destroy the iax2 private
structure and move on. If there is a channel, it queues a HANGUP frame,
and expects that to make the ast_channel get torn down, which would then
cause the pvt struct to get destroyed afterwards.

However, since there was no PBX started on this channel, there is nothing
servicing the channel to receive the HANGUP frame. Therefore, the call
never gets destroyed. To make things worse, there is some code
continuously rescheduling PINGs and LAGRQs to be sent for the active IAX2
call, which will always fail.

In summary, sending a bunch of NEW frames to request unauthenticated calls
can make a server unusable within a matter of seconds.

Resolution
The default configuration that is distributed with Asterisk includes a
guest account that allows unauthenticated calls. If this account and any
other account without a password is disabled for IAX2, then the system is
not vulnerable to this problem. For systems that continue to allow
unauthenticated IAX2 calls, they must be updated to one of the versions
listed as including the fix below.

ADDITIONAL INFORMATION

The information has been provided by <mailto:russell@digium.com> Russell
Bryant, Digium, Inc..
The original article can be found at:
<http://ftp.digium.com/pub/asa/ASA-2007-018.pdf>

http://ftp.digium.com/pub/asa/ASA-2007-018.pdf

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.