[asterisk-bugs] [JIRA] (ASTERISK-25139) Malicious transfer sequence locks up Asterisk

Gregory Massel (JIRA) noreply at issues.asterisk.org
Fri May 29 10:30:33 CDT 2015


Gregory Massel created ASTERISK-25139:
-----------------------------------------

             Summary: Malicious transfer sequence locks up Asterisk
                 Key: ASTERISK-25139
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25139
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Channels/chan_sip/General
    Affects Versions: 11.16.0
         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.0
            Reporter: Gregory Massel
            Severity: Critical


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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list