[Full-disclosure] ASA-2007-018: Resource exhaustion vulnerability in IAX2 channel driver

           Asterisk Project Security Advisory - ASA-2007-018

±-----------------------------------------------------------------------+
| Product | Asterisk |
|--------------------±--------------------------------------------------|
| Summary | Resource Exhaustion vulnerability in IAX2 channel |
| | driver |
|--------------------±--------------------------------------------------|
| Nature of Advisory | Denial of Service |
|--------------------±--------------------------------------------------|
| Susceptibility | Remote Unauthenticated Sessions |
|--------------------±--------------------------------------------------|
| Severity | Moderate |
|--------------------±--------------------------------------------------|
| Exploits Known | No |
|--------------------±--------------------------------------------------|
| Reported On | July 19, 2007 |
|--------------------±--------------------------------------------------|
| Reported By | Russell Bryant, Digium, Inc. <[email protected]> |
|--------------------±--------------------------------------------------|
| Posted On | July 23, 2007 |
|--------------------±--------------------------------------------------|
| Last Updated On | July 25, 2007 |
|--------------------±--------------------------------------------------|
| Advisory Contact | Russell Bryant <[email protected]> |
|--------------------±--------------------------------------------------|
| CVE Name | |
±-----------------------------------------------------------------------+

±-----------------------------------------------------------------------+
| Description | 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. |
| | |
| | Detailed Explanation: |
| | |
| | Within the last few months, we 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. We 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 |
| | afterwords. |
| | |
| | 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. |
±-----------------------------------------------------------------------+

±-----------------------------------------------------------------------+

±-----------------------------------------------------------------------+

±-----------------------------------------------------------------------+
| Links | |
±-----------------------------------------------------------------------+

±-----------------------------------------------------------------------+
| Asterisk Project Security Advisories are posted at |
| [LINK][LINK]http://www.asterisk.org/security[LINK][LINK]. |
| |
| This document may be superseded by later versions; if so, the latest |
| version will be posted at |
| http://ftp.digium.com/pub/asa/ASA-2007-018.pdf. |
±-----------------------------------------------------------------------+

±-----------------------------------------------------------------------+

           Asterisk Project Security Advisory - ASA-2007-018
          Copyright (c) 2007 Digium, Inc. All Rights Reserved.

Permission is hereby granted to distribute and publish this advisory in its
original, unaltered form.

Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/