[asterisk-bugs] [JIRA] (ASTERISK-22920) Crash while Forwarding from TLS extension with CHANNEL args secure_bridge_media and secure_bridge_signaling

[Alexander Traud (JIRA)]

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

Alexander Traud edited comment on ASTERISK-22920 at 4/27/20 11:09 AM:
----------------------------------------------------------------------

First of all, thank you for reporting this issue. Without reports like this, everyone would consume Asterisk and not contribute something back to the community.

[~voicenter], like you, I am an external contributor. However, because of a bit of spare time, I look into the remaining chan_sip/TLS and SDES-sRTP issues. I was able to reproduce your setup and the crash. It simply needs a phone which allows forwarding via SIP status 302 like a recent [Snom|https://service.snom.com/display/wiki/Call+Forwarding].

The provided logs contain two important puzzle pieces: “Channel 'Local/…' may not have been hung up properly”. That is the last log entry before the crash. (1) Asterisk tried to release that channel. (2) The channel type is not ‘SIP’ as usual but ‘Local’ because of the call forwarding. Local uses ao2_ref (reference counting) when it comes to releasing. Therefore, the wrong release function was called – it worked for {{chan_sip}} but not in general.

Long story short, the crash was fixed with [GERRIT-3725|https://gerrit.asterisk.org/3725]. Consequently, ASTERISK-26306 was a duplicate of this issue report. I simply missed it. Thanks to the comment from Richard Mudgett, a core member of the Asterisk team, the crash is fixed since Asterisk 11.24.0 and Asterisk 13.12.0.

I wonder why nobody increased the severity to ‘critical’ here. An external entity, a SIP phone attached to Asterisk is able to crash Asterisk, depending on the configuration of the phone. Yeek!

However, your issue report (and your proposed patch) is about more. It is about a working {{secure_bridge_media}} even in case of call forwarding. Therefore, the solution to ASTERISK-26306 just decreased the severity of your report from critical to major. Consequently, I had to look deeper into your proposed patch. I went for a conservative approach and changed just Local Proxy and not all channel drivers, because: There are channel drivers which do not support these items like the new SIP channel driver PJSIP. That should be written somewhere as a warning.

Anyway, I attached both alternatives, your approach {{A_channel.patch}} and my approach {{B_local.patch}}. Perhaps the Asterisk team finds more (local) channel drivers, which can be covered, for example, changing {{ast_unreal_setoption}} in core_unreal. I do not know. That would be a middle course between your and my approach. I submitted my approach for review. Hope you like it, Shlomi (and everyone else watching this issue). Otherwise, please, comment!


was (Author: traud):
First of all, thank you for reporting this issue. Without reports like this, everyone would consume Asterisk and not contribute something back to the community.

[~voicenter], like you, I am an external contributor. However, because of a bit of spare time, I look into the remaining chan_sip/TLS and SDES-sRTP issues. I was able to reproduce your setup and the crash. It simply needs a phone which allows forwarding via SIP status 302 like a recent [Snom|https://service.snom.com/display/wiki/Call+Forwarding].

The provided logs contain two important puzzle pieces: “Channel 'Local/…' may not have been hung up properly”. That is the last log entry before the crash. (1) Asterisk tried to release that channel. (2) The channel type is not ‘SIP’ as usual but ‘Local’ because of the call forwarding.

Long story short, the crash was fixed with [GERRIT-3725|https://gerrit.asterisk.org/3725]. Consequently, ASTERISK-26306 was a duplicate of this issue report. I simply missed it. Thanks to the comment from Richard Mudgett, a core member of the Asterisk team, the crash is fixed since Asterisk 11.24.0 and Asterisk 13.12.0.

I wonder why nobody increased the severity to ‘critical’ here. An external entity, a SIP phone attached to Asterisk is able to crash Asterisk, depending on the configuration of the phone. Yeek!

However, your issue report (and your proposed patch) is about more. It is about a working {{secure_bridge_media}} even in case of call forwarding. Therefore, the solution to ASTERISK-26306 just decreased the severity of your report from critical to major. Consequently, I had to look deeper into your proposed patch. I went for a conservative approach and changed just Local Proxy and not all channel drivers, because: There are channel drivers which do not support these items like the new SIP channel driver PJSIP. That should be written somewhere as a warning.

Anyway, I attached both alternatives, your approach {{A_channel.patch}} and my approach {{B_local.patch}}. Perhaps the Asterisk team finds more (local) channel drivers, which can be covered, for example, changing {{ast_unreal_setoption}} in core_unreal. I do not know. That would be a middle course between your and my approach. I submitted my approach for review. Hope you like it, Shlomi (and everyone else watching this issue). Otherwise, please, comment!

> Crash while Forwarding from TLS extension with CHANNEL args secure_bridge_media and secure_bridge_signaling
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-22920
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22920
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_srtp
>    Affects Versions: 1.8.14.0, 1.8.24.0, 11.2.2, 11.5.0, 11.6.0, 11.7.0, 13.18.4
>         Environment: CentOS release 5.8 (Final)  kernel 2.6.18-308.24.1.el5 64bit, libsrtp 1.4.2(compiled manually)  with 1.8.14 with and without patch (https://issues.asterisk.org/jira/browse/ASTERISK-18345)
> Debian GNU/Linux 7 (wheezy) kenrel 3.2.0-4-amd64 (3.2.51-1 64bit), with above patch on 11.5.0 and without patch on 1.8.24.0 11.7.0-rc1 11.6.0
> with libsrtp 1.4.4 (from debian repo), self compiled 1.4.2, as well as 1.4.4 self compiled and self compiled with patch ( http://srtp.cvs.sourceforge.net/viewvc/srtp/srtp/crypto/replay/rdb.c?r1=1.4&r2=1.5) as mentioned on https://issues.asterisk.org/jira/browse/ASTERISK-16665
> 2 phones were tested snom 710 and fanvil C62 
>            Reporter: Shlomi Gutman
>              Labels: patch
>         Attachments: A_channel.patch, backtrace_ldd.log, B_local.patch, debug.log, exten_incoming.conf, extension_realtime.info, gdb.log, ldd.log, rnewton_backtrace.txt, rnewton_sip.txt, sip.conf
>
>
> Steps to reproduce:
> 1)Asterisk with self signed certificates or GoDaddy certificates
> 2)Extension connected with TLS transport (behind NAT in our case)
> 3)Route incoming call to that extension, while forward call from it without answering (302 - FORWARD)
> 4)Crash
> I know that this bug may be related to srtp, but as we see it was not developed and maintained for a long time and as asterisk srtp based on itץ
> I think at least it should crash the call only, but not whole asterisk.



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