[asterisk-bugs] [JIRA] (ASTERISK-28465) Broken SDP can cause a segfault in a T.38 reINVITE

[Asterisk Team (JIRA)]

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

Asterisk Team updated ASTERISK-28465:
-------------------------------------

    Target Release Version/s: 16.4.1

> Broken SDP can cause a segfault in a T.38 reINVITE
> --------------------------------------------------
>
>                 Key: ASTERISK-28465
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28465
>             Project: Asterisk
>          Issue Type: Security
>          Components: Channels/chan_sip/Interoperability
>    Affects Versions: 13.27.0
>         Environment: asterisk-13.23.0 on Debian/Jessie, with T.38, and sip_preferred_codec_only reINVITE enabled
>            Reporter: Francesco Castellano
>            Assignee: Joshua C. Colp
>            Severity: Blocker
>              Labels: security
>      Target Release: 13.27.1, 15.7.3, 16.4.1
>
>         Attachments: crash-t38-broken-answer-with-empty-jointcaps.xml
>
>
> Our gateways (asterisk-13 based) experienced occasional segfaults last days, and inspecting with GDB their coredumps, we finally concluded they are caused by a very specific case in process_sdp() of chan_sip.c:
> 1) Asterisk has been configured with {{preferred_codec_only}} for the relevant peer, and e list, possibly restrictive, of codecs
> 2) the SIP peer starts a valid session through Asterisk (chan_sip) as a B2BUA
> 3) Asterisk issue a T.38 reINVITE (for example with ReceiveFAX application, even if it was not our case)
> 4) the SIP UA (UAS in this case) responds with a "broken" SDP with two m-lines, one for an audio codec _not_ included in the SIP peer allowed list, and another with image/t38
> Such an SDP is broken because a SIP UA is not allowed to responds with multiple m-lines whenever it received just one m-line.
> We reproduced it on a lab with SIPp and the last version *13* released (13.27.0), but I see no change on that part of code also on *master*.
> The reason I choose to tag it as a security issue, is that:
> * with specific configurations
> * a malevolent, authenticated (it can setup a call through the Asterisk server) user
> * can tear down the service
> But I'm not sure it is so serious: I'm inviting you to properly change it.



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