Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | [UNIX] IAX2 Channel Driver Resource Exhaustion Vulnerability |
|---|---|
| Date: | 1 Aug 2007 09:27:12 +0200 |
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.
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Next by Date: | [NT] BlueSkyChat ActiveX Remote Heap Overflow vulnerability, SecuriTeam |
|---|---|
| Next by Thread: | [NT] BlueSkyChat ActiveX Remote Heap Overflow vulnerability, SecuriTeam |
| Indexes: | [Date] [Thread] [Top] [All Lists] |