[Home]

Summary:ASTERISK-26461: chan_sip: SIP MESSAGE body parsed incorrectly (as headers) if first character is a space (0x20)
Reporter:Alex Villacís Lasso (a_villacis)Labels:chan-sip-message-parsing patch
Date Opened:2016-10-12 16:29:11Date Closed:2021-10-27 15:52:51
Priority:MinorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:11.23.1 13.18.4 Frequency of
Occurrence
Related
Issues:
is duplicated byASTERISK-28693 chan_sip: SIP MESSAGE beginning with a whitespace appears empty in the dialplan
is related toASTERISK-27045 Issue with Parsing Contact Header without Brackets and with additional HeaderParameters seperated with semicolon
Environment:Attachments:( 0) asterisk-11.23.1-ASTERISK-26461-fix-body-misparsed-as-headers.patch
Description:If pedantic=yes is enabled in chan_sip configuration (the default if no setting is specified), a SIP request sent through any channel (UDP and WebSocket tested) that includes a body that starts with a space character will cause the SIP request to be misparsed in such a way that at least some of the content of the request body ends up interpreted as headers.

This issue was found out when sending SIP MESSAGE requests, but from my code examination, it potentially affects all incoming SIP requests, and possibly responses too.

To reproduce this:

* Prepare an asterisk 11.23.1 server to receive out-of-call SIP MESSAGE requests.

* Configure a SIP client capable of sending a SIP MESSAGE request. I could reproduce this with both SIP.js 0.7.5 and Linphone 3.6.1 .

* Send a text similar to the following (without the separators):

{noformat}
xyzxy
Alguna: Cosa
ABC: DEF
{noformat}

Note that the first line of the message is " xyzxy". That is, SPACE followed by a 5-letter string).

* Follow "sip set debug on" with "core set debug 4" in the Asterisk console.


What I see is the following output:

{noformat}
<--- SIP read from WS:127.0.0.1:33692 --->
MESSAGE sip:7337@elx4-2.elastix.palosanto.com SIP/2.0
Via: SIP/2.0/WSS 192.0.2.89;branch=z9hG4bK5459865
Max-Forwards: 70
To: <sip:7337@elx4-2.elastix.palosanto.com>
From: "Alex Villacís Lasso" <sip:1064@elx4-2.elastix.palosanto.com>;tag=e5jh5ftku8
Call-ID: ka3o6frhobrhk95ce7vf
CSeq: 5238 MESSAGE
Authorization: Digest algorithm=MD5, username="1064", realm="asterisk", nonce="3e6df95c", uri="sip:7337@elx4-2.elastix.palosanto.com", response="99b9bb8e0a354be51cb527da32661225"
Content-Type: text/plain
Supported: 100rel, outbound
User-Agent: SIP.js
Content-Length: 29
xyzxy
Alguna: Cosa
ABC: DEF
<------------->
[2016-10-12 13:39:30] DEBUG[2187]: chan_sip.c:9527 parse_request: Header  0 [ 53]: MESSAGE sip:7337@elx4-2.elastix.palosanto.com SIP/2.0
[2016-10-12 13:39:30] DEBUG[2187]: chan_sip.c:9527 parse_request: Header  1 [ 49]: Via: SIP/2.0/WSS 192.0.2.89;branch=z9hG4bK5459865
[2016-10-12 13:39:30] DEBUG[2187]: chan_sip.c:9527 parse_request: Header  2 [ 16]: Max-Forwards: 70
[2016-10-12 13:39:30] DEBUG[2187]: chan_sip.c:9527 parse_request: Header  3 [ 43]: To: <sip:7337@elx4-2.elastix.palosanto.com>
[2016-10-12 13:39:30] DEBUG[2187]: chan_sip.c:9527 parse_request: Header  4 [ 83]: From: "Alex Villacís Lasso" <sip:1064@elx4-2.elastix.palosanto.com>;tag=e5jh5ftku8
[2016-10-12 13:39:30] DEBUG[2187]: chan_sip.c:9527 parse_request: Header  5 [ 29]: Call-ID: ka3o6frhobrhk95ce7vf
[2016-10-12 13:39:30] DEBUG[2187]: chan_sip.c:9527 parse_request: Header  6 [ 18]: CSeq: 5238 MESSAGE
[2016-10-12 13:39:30] DEBUG[2187]: chan_sip.c:9527 parse_request: Header  7 [178]: Authorization: Digest algorithm=MD5, username="1064", realm="asterisk", nonce="3e6df95c", uri="sip:7337@elx4-2.elastix.palosanto.com", response="99b9bb8e0a354be51cb527da32661225"
[2016-10-12 13:39:30] DEBUG[2187]: chan_sip.c:9527 parse_request: Header  8 [ 24]: Content-Type: text/plain
[2016-10-12 13:39:30] DEBUG[2187]: chan_sip.c:9527 parse_request: Header  9 [ 27]: Supported: 100rel, outbound
[2016-10-12 13:39:30] DEBUG[2187]: chan_sip.c:9527 parse_request: Header 10 [ 18]: User-Agent: SIP.js
[2016-10-12 13:39:30] DEBUG[2187]: chan_sip.c:9527 parse_request: Header 11 [ 18]: Content-Length: 29
[2016-10-12 13:39:30] DEBUG[2187]: chan_sip.c:9527 parse_request: Header 12 [  6]:  xyzxy
[2016-10-12 13:39:30] DEBUG[2187]: chan_sip.c:9527 parse_request: Header 13 [ 12]: Alguna: Cosa
[2016-10-12 13:39:30] DEBUG[2187]: chan_sip.c:9564 parse_request: Header 14 [  8]: ABC: DEF
--- (15 headers 0 lines) ---
{noformat}

As shown here, headers 0 through 11 are valid. However, the body has been misparsed and assigned as headers 12 through 14.


This bug messes up SIP message processing and causes MESSAGE(body) to be empty in the dialplan. At first, I was going to open a simple public issue. However, I am sending it as a suspected vulnerability because:

1) This enables end users to insert arbitrary SIP headers with arbitrary content, bypassing any validation done by the SIP client. This could potentially allow easier exploitation of other vulnerabilities that require attacker-supplied content in SIP headers.

2) This could mess up any place in the Asterisk code where Content-Length is assumed to be correct after parsing.


My prime suspect is the function lws2sws() in channels/chan_sip.c incorrectly considering the line of the body with the space as part of a multiline header.
Comments:By: Walter Doekes (wdoekes) 2016-10-12 16:46:05.131-0500

Confirmed. The CRLF CRLF SP is reduced down to CRLF SP and the message body is interpreted as headers. This works for other requests than MESSAGE too.

If this is fixed by stopping the lws2sws() rewrites at CRLF CRLF, we may want to look into ASTERISK-18919 (stopping rewrites in parse_request) too at the same time.
By: Rusty Newton (rnewton) 2016-10-12 17:46:11.029-0500

Opening this up since it is a bug.

I'm removing the viewing restriction as [~mmichelson], [~gjoseph] and [~jcolp] determined that this shouldn't be a vulnerability.
By: Rusty Newton (rnewton) 2016-10-12 17:47:28.279-0500

[~a_villacis] thanks for reporting this the way you did. Better safe than sorry.

[~wdoekes] thanks for confirming the issue!
By: Alex Villacís Lasso (a_villacis) 2016-10-12 17:59:39.872-0500

This patch enables recognition of the SIP request body when collapsing headers. When the start of the body is recognized, the change just memmove()s the rest of the data and exits the loop. This fixes the issue of body misparsing in my local tests, and also leaves the message body as received.
By: Sean Bright (seanbright) 2021-10-27 15:53:27.526-0500

Fixed by https://gerrit.asterisk.org/c/asterisk/+/13638