[asterisk-bugs] [JIRA] (ASTERISK-26461) chan_sip: SIP MESSAGE body parsed incorrectly (as headers) if first character is a space (0x20)

Wed Oct 27 15:53:50 CDT 2021

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

Sean Bright commented on ASTERISK-26461:
----------------------------------------

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

> chan_sip: SIP MESSAGE body parsed incorrectly (as headers) if first character is a space (0x20)
> -----------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-26461
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26461
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/General
>    Affects Versions: 11.23.1, 13.18.4
>            Reporter: Alex Villacís Lasso
>              Labels: chan-sip-message-parsing
>         Attachments: asterisk-11.23.1-ASTERISK-26461-fix-body-misparsed-as-headers.patch
>
>
> 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 at 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 at elx4-2.elastix.palosanto.com>
> From: "Alex Villacís Lasso" <sip:1064 at 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 at 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 at 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 at 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 at 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 at 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.


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