IAX Poke Resource Exhaustion
While preparing for The Last HOPE, Blake Cornell discovered the fact that given a flood of IAX ‘POKE’ requests one could affect the operation of Asterisk.
The moment Blake informed me and I was able to replicate the sitaution, I promptly informed Digium via a quick IRC-based private discussion with multiple Digium employees. However my non-standard disclosure to Digium was for whatever reasons not acted upon and an already created patch had not been applied to the Asterisk source trees.
Blake and I proceeded to give our presentation at HOPE. Shortly after our presentation, as promised, Blake released his simple perl script, which was primarily intended to scan netblocks looking for running IAX services. However there was a ‘DoS’ option, which demonstrates the IAX Poke resource exhaustion.
From the Asterisk Security Advisory - AST-2008-010:
By flooding an Asterisk server with IAX2 ‘POKE’ requests, an attacker may eat up all call numbers associated with the IAX2 protocol on an Asterisk server and prevent other IAX2 calls from getting through. Due to the nature of the protocol, IAX2 POKE calls will expect an ACK packet in response to the PONG packet sent in response to the POKE. While waiting for this ACK packet, this dialog consumes an IAX2 call number, as the ACK packet must contain the same call number as was allocated and sent in the PONG.
I have since been informed by no less than a dozen people (plus on the disclosure itself) that this was an irresponsible security disclosure. However, I feel I did the right thing by informing Digium the moment I was able to duplicate the sitaution….Perhaps people were confused by the wording of the advisory by Digium.
Filed under: Asterisk, iax2, vulnerability
In all honesty, I didn’t fully understand the impact of the exploit, since I had only discovered the issue a few days before HOPE by accident.
Not only was there a 1 to 9 CPU utilization ratio between the attacker and the victim (bad enough), but there was, as well, the limited call number resource issue!! The exploit results in a complete shutdown of IAX services with very little effort.
If Digium had officially stated that they are concerned about the bug and don’t want this exploit published nor mentioned at a HACKER convention, do you think I would have published it? None the less, I feel as if Digium simply dragged their feet and are using ‘YOU’ as a scape goat, all the while committing libel against you.
Shame Shame Shame on Digium…
Maybe next time they will listen. (foreshadowing??)
I believe we have had some miscommunication here.
When I was informed of the issue, it was presented as a security issue. We took the issue very seriously, and acted on it immediately. Tilghman Lesher and myself discussed the issue until we decided upon a proper approach to address the issue. Tilghman wrote the patch that we decided upon and presented it to you (Jeremy), to which you responded “interesting”. The patch was written _after_ you told us about it.
At that point, we were waiting on verification from you that it resolved the issue, as that is standard practice when handling issues like this. We waited a few days for your response, but the response came in the form of a public disclosure of the issue.
This is where the “irresponsible disclosure” part comes in. The details of the security issue, as well as as exploit script, were released before we were given the opportunity to release versions of Asterisk that included the fix. Proper disclosure practices would have it such that we are given the opportunity to release versions of the software with a fix before a coordinated release of the details of the security vulnerability.
When dealing with security issues in the future, we need to have better communication so that releases can be provided to users of Asterisk before the details of security problems are released to the public.