[Home]

Summary:ASTERISK-25139: Malicious transfer sequence locks up Asterisk
Reporter:Gregory Massel (gmza)Labels:
Date Opened:2015-05-29 10:30:03Date Closed:2015-06-16 10:01:14
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:11.16.0 Frequency of
Occurrence
Occasional
Related
Issues:
Environment:Linux tissip1 3.13.0-46-generic #79-Ubuntu SMP Tue Mar 10 20:06:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Asterisk 11.16.0Attachments:( 0) 2015-05-29_Call_that_crashed_Asterisk.pcapng
Description:A sequence of malicious SIP signalling ending with a BYE/Also method crashes Asterisk in a similar manner to the AST-2008-001 Denial-of-Service.

Asterisk logs:
[May 29 14:08:11] NOTICE[21356][C-0005f0ca] chan_sip.c: Client '197.81.91.106:5060' using deprecated BYE/Also transfer method.  Ask vendor to support REFER instead

Within seconds after that, most call signalling locks up.
The IAX2 channel driver gets caught logging thousands of:
[May 29 14:08:27] WARNING[21364] chan_iax2.c: Received trunked frame before first full voice frame
although that is secondary. Even SIP signalling crashes, albeit without associated log entries.
Asterisk won't shut down cleanly and has to be kill -9'ed and restarted.

PCAPs of the calls show that this doesn't happen in every instance of a BYE/Also signal, only when the BYE/Also follows something else within the signalling (possibly a failed attempt to transfer).

In all cases, sip.conf allowtransfer=no so no transfer should be effected.

The lock-up happens virtually instatantaneously after the BYE/Also packet. In fact, a PCAP shows that Asterisk - while managing to log a warning about that, fails to issue a SIP ACK (or any further SIP signalling) thereafter.

While I cannot replicate this, it is happening frequently, particularly when fraudulent calls are attempted. I shall attach a PCAP of a call that has caused this sequence.
Comments:By: Rusty Newton (rnewton) 2015-05-29 17:19:14.559-0500

If you were not able to file the issue with the proper security level then you should have let us know before posting. Now a notification with the issue was sent out to the public... which is not a good thing. It is always nice to have a chance to fix the problem before publicizing it.

I see now that it appears users can no longer set their own security level on ticket creation.

In the future, create a blank ticket and then ask a bug marshal to set the security level before adding in the detail. That or we will just create the issue for you if you ask.

I'll modify the wiki documentation to make this very clear and notify all the other bug marshals and parties involved on the process.

By: Rusty Newton (rnewton) 2015-05-29 17:39:58.833-0500

We suspect that you have a deadlock occurring within Asterisk. Please follow the instructions on the wiki [1] for obtaining debug relevant to a deadlock. Once you have that information, attach it to the issue. Be sure the instructions are followed exactly as the debug may otherwise not be useful.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace#GettingaBacktrace-GettingInformationForADeadlock



By: Rusty Newton (rnewton) 2015-05-29 17:44:38.030-0500

In addition we'll need a log along with the trace and locking output. Please follow the instructions on the wiki [1] for how to collect debugging information from Asterisk. For expediency, where possible, attach the debug with a '.txt' file extension so that the debug will be usable for further analysis.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information



By: Mark Michelson (mmichelson) 2015-06-11 16:52:07.347-0500

I have managed to reproduce the problem, and I have determined that this is not a security issue since this cannot be exploited at will.

There is a race condition where there is lock inversion in the code path where the Also: header on a SIP BYE is processed. This has the potential to cause a deadlock, but it's not a sure thing every time. I have a fix that has caused the problem not to happen for me, and I am putting it up on gerrit for code review. I will provide a link once the review is up.

By: Mark Michelson (mmichelson) 2015-06-11 16:57:23.584-0500

Gerrit review is here: https://gerrit.asterisk.org/#/c/644/

By: Bobby Hakimi (bobbymc) 2015-10-15 13:40:07.671-0500

im still having this issue with version 11.17.1. im not as advanced with code but this issue happens in our production system every day. is there any chance someone can help me understand what commands to run or what debug commands to run until it happens so i can provide you guys with all the data needed?