[asterisk-bugs] [JIRA] (ASTERISK-24136) Security: Crash in Asterisk's PJSIP code when subscribing to an event with an unexpected body type

[Matt Jordan (JIRA)]

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

Matt Jordan updated ASTERISK-24136:
-----------------------------------

    Target Release Version/s: 13.0.0-beta2

> Security: Crash in Asterisk's PJSIP code when subscribing to an event with an unexpected body type
> --------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-24136
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24136
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip_pubsub
>    Affects Versions: 12.1.0, 12.1.1, 12.2.0, 12.3.0, 12.3.1, 12.4.0
>            Reporter: Mark Michelson
>            Severity: Critical
>              Labels: Security
>      Target Release: 12.5.1, 12.6.0, 13.0.0-beta2
>
>         Attachments: uac-subscribe-mismatch.xml
>
>
> It is possible to cause Asterisk to crash by sending a SIP SUBSCRIBE request that has an unexpected combination of Event: and Accept: headers present.
> In my attached SIPp scenario, I crash Asterisk by subscribing to the event "message-summary" but stating that I accept "application/pidf+xml".
> When the SUBSCRIBE arrives, Asterisk checks that it has a subscription handler for the message-summary event and that it has a body generator for PIDF. Both checks succeed, so the subscription is accepted.
> Asterisk then attempts to generate a NOTIFY request to send. The message-summary event code generates a structure that is not expected to be used by the PIDF body generator. Since void pointers are used as teh inputs to body generators, the input gets cast to the wrong type, and a crash occurs.
> The crash has a few requirements in order to succeed:
> 1) The SUBSCRIBE has to arrive from a known endpoint and has to pass any authentication in place.
> 2) The SUBSCRIBE needs to be for a known resource. The crash will not happen if the requested resource is not found or if configuration does not allow for the resource to be subscribed to.
> 3) The subscribe handler that corresponds to the Event header and the body generator that corresponds to the Accept header need to be loaded. If they are not loaded, then the crash will not occur.
> Fixing this means introducing some sort of type safety into the mix. When Asterisk chooses a subscription handler, the handler should have something set on it, saying "I generate body data of type BLAH". Similarly, body generators should indicate "I expect to be given body data of type BLAH". If the BLAHs do not match, reject the subscription.
> To further prevent the issue, instead of passing void pointers to body generators, type information needs to be conveyed. This way body generators and body supplements can inspect the type of the data that is coming to them and fail early if the data is not of the type they expect.
> Note that I am checking the Regression box on this issue. Version 12.0.0 does not exhibit this crash. The introduction of body generators in 12.1.0 introduced this crash.



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