Summary:	ASTERISK-24136: Security: Crash in Asterisk's PJSIP code when subscribing to an event with an unexpected body type
Reporter:	Mark Michelson (mmichelson)	Labels:	Security
Date Opened:	2014-07-30 11:27:03	Date Closed:	2014-09-18 10:42:08
Priority:	Critical	Regression?	Yes
Status:	Closed/Complete	Components:	Resources/res_pjsip_pubsub
Versions:	12.1.0 12.1.1 12.2.0 12.3.0 12.3.1 12.4.0	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) uac-subscribe-mismatch.xml
Description:	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.
Comments:	By: Mark Michelson (mmichelson) 2014-07-30 11:27:41.937-0500 Attaching uac-subscribe-mismatch.xml. This can be used to crash Asterisk. By: Matt Jordan (mjordan) 2014-07-30 11:31:12.971-0500 Poo. By: Mark Michelson (mmichelson) 2014-07-31 09:16:10.629-0500 Reviews for this issue can be found in the following links: [Asterisk 12 Patch|https://reviewboard.asterisk.org/r/3877/] [Trunk Patch|https://reviewboard.asterisk.org/r/3878/] [Testsuite Test|https://reviewboard.asterisk.org/r/3879/] By: Paul Belanger (pabelanger) 2014-07-31 10:30:21.702-0500 Not that I can comment much, but I get an exception when trying to look at the patches. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. By: Matt Jordan (mjordan) 2014-07-31 10:41:41.504-0500 That's because you didn't ask to be in the security group on review board :-) By: Mark Michelson (mmichelson) 2014-07-31 10:46:28.614-0500 That's a good sign, at least, that I didn't accidentally publish the review request to the world. By: Rusty Newton (rnewton) 2014-08-01 12:43:15.867-0500 I can't see the patches either. I need to be put in the security group on reviewboard I guess.