[asterisk-bugs] [JIRA] (ASTERISK-22920) Crash while Forwarding from TLS extension

[Shlomi Gutman (JIRA)]

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

Shlomi Gutman commented on ASTERISK-22920:
------------------------------------------

I think i found the problem and solution but not really sure if it's the best option and if it's should be done that way(new to asterisk code, new to C).
I tried to detect if the channel is secure and just not run ast_free on chan->tech_pvt but i failed as it seems to be always be unsecure.
Then i remembered that there was warning saying( which would be related to the second problem we talked about) :
" WARNING[20339][C-00000000]: channel.c:5952 ast_request: Setting security requirements failed"
I decided to try to use the fix i used before:
{code}
--- channel.c.org       2014-01-07 18:58:45.396465980 +0200
+++ channel.c   2014-01-07 19:00:13.704244067 +0200
@@ -5855,15 +5855,15 @@ static int set_security_requirements(con
        ast_channel_unlock(r);

        for (i = 0; i < 2; i++) {
-               if (ops[i][1]) {
-                       if (ast_channel_setoption(out, ops[i][0], &ops[i][1], sizeof(ops[i][1]), 0)) {
+//             if (ops[i][1]) {
+//                     if (ast_channel_setoption(out, ops[i][0], &ops[i][1], sizeof(ops[i][1]), 0)) {
                                /* We require a security feature, but the channel won't provide it */
-                               return -1;
-                       }
-               } else {
+//                             return -1;
+//                     }
+//             } else {
                        /* We don't care if we can't clear the option on a channel that doesn't support it */
                        ast_channel_setoption(out, ops[i][0], &ops[i][1], sizeof(ops[i][1]), 0);
-               }
+//             }
        }

        return 0;
{code}

But i'm not sure that this wouldn't break anything else. If it wouldn't break srtp support in any specific places or it will break forward from secured call to regular extension and so on...
So it need to be reviewed and debugged, i'll try to update once i'll have more info.

P.S.
Would like to know if anyone can reproduce crash? as it's 100% reproducable for me for few versions (including 11.7.0) and several distros(debian/centos) and even different hw and i don't see too much activity/comments here.



                
> Crash while Forwarding from TLS extension
> -----------------------------------------
>
>                 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.5.0, 11.6.0, 11.7.0
>         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
>            Assignee: Shlomi Gutman
>         Attachments: backtrace_ldd.log, debug.log, exten_incoming.conf, extension_realtime.info, gdb.log, ldd.log, 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira