[asterisk-bugs] [JIRA] (ASTERISK-18919) SIP MESSAGE body is not used verbatim

[Joshua Colp (JIRA)]

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

Joshua Colp updated ASTERISK-18919:
-----------------------------------

    Affects Version/s: 13.18.4

> SIP MESSAGE body is not used verbatim
> -------------------------------------
>
>                 Key: ASTERISK-18919
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-18919
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/Interoperability
>    Affects Versions: 1.8.7.1, 13.18.4
>            Reporter: Walter Doekes
>            Severity: Minor
>
> Per the request of Matt Jordan, I'm filing this request for an unmodified SIP request body.
> http://lists.digium.com/pipermail/asterisk-dev/2011-November/052401.html
> chan_sip parse_request() does the following:
> - loop over the entire SIP message (req->data)
> - replace (CR)LF with NUL
> - store pointers to the modified buffer, one array of header lines (req->header[] and one array for body lines req->line[])
> The header and body lines are then referenced using: REQ_OFFSET_TO_STR(req, header[x]) / REQ_OFFSET_TO_STR(req, line[x])
> For SIP parsing, this is fine. In pedantic mode lws2sws() preprocesses the data, so single line headers can be expected.
> For SDP (SIP body) parsing, having the body split up by line is nice too.
> For other SIP body uses this may not be nice.
> One particular instance is the SIP MESSAGE. When fetching the SIP MESSAGE body, we reassemble the body by concatenating it with a single linefeed. This means that:
> - messages without a line feed can get a trailing newline added (there is a workaround in place)
> - messages with NULs in them will always be terminated at the NUL (fixing this is probably beyond the scope)
> - messages with CRs are will have them replaced with LFs or ignored if just before another LF
> Is the MESSAGE Content-Type is text/plain, this will probably not be a problem, but other message types may require a bit more binary safety.
> My suggestion would be to have parse_request() stop parsing the body and have someone else continue parsing it only when it is deemed useful (for SDP parsing).



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