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

[Bobby Hakimi (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-25139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=227882#comment-227882 ] 

Bobby Hakimi commented on ASTERISK-25139:
-----------------------------------------

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?


> 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: Rusty Newton
>            Severity: Critical
>      Target Release: 11.19.0
>
>         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)