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

[Mark Michelson (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Michelson updated ASTERISK-25139:
--------------------------------------

    Security:     (was: Reporter, Bug Marshals, and Digium)

> Malicious transfer sequence locks up Asterisk
> ---------------------------------------------
>
>                 Key: ASTERISK-25139
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25139
>             Project: Asterisk
>          Issue Type: Bug
>          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
>            Assignee: Gregory Massel
>            Severity: Critical
>         Attachments: 2015-05-29 Call that crashed Asterisk.pcapng
>
>
> 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)