textops: get_body_part doesn't detect multipart headers ending properly

[foucse]

When I use get_body_part on a multipart body, it doesn't detect properly the ending of multipart headers:

For instance in:

--vvemeemm0wqr7ayc5h367f3v8e66mc9t
Content-Type: application/sdp
Content-Length: 479

v=0
o=- 3669362310 3669362310 IN IP4 192.168.2.4
[...]

"Content-Length: 479" is taken into get_body_part("application/sdp", "$var(sdp)");

I will try to provide more details later.

[kamailio-sync]

I have no example of a multipart body in my pile of cool INVITE messages. Would it be possible for
you to upload one full INVITE as an example for us to test with?

/O

On 11 Apr 2016, at 13:20, foucse notifications@github.com wrote:

When I use get_body_part on a multipart body, it doesn't detect properly the ending of multipart headers:

For instance in:

--vvemeemm0wqr7ayc5h367f3v8e66mc9t
Content-Type: application/sdp
Content-Length: 479

v=0
o=- 3669362310 3669362310 IN IP4 192.168.2.4
[...]
"Content-Length: 479" is taken into get_body_part("application/sdp", "$var(sdp)");

I will try to provide more details later.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub #564

---

sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[foucse]

Hi,

Here is one example, the XML body is not standard (yet), so I had to remove it. Content-Length is to be checked

2016/04/11 16:38:17.645936 192.168.2.2:5062 -> 192.168.100.1:5060
INVITE sip:bob@example.com SIP/2.0
via: SIP/2.0/UDP 192.168.2.2:5062;branch=z9hG4bK-18344-1-10
From: "alice" <sip:alice@example.com>;tag=183446416897
To: "bob" <sip:bob@example.com>
Call-ID: alice-bob-call
CSeq: 2 INVITE
Contact: <sip:alice@192.168.2.2:5062>
Max-Forwards: 70
Expires: 3600
Content-Type: multipart/mixed;boundary=8920nv9wiwdnnsrnia9buoyci39qsi6x
Content-Disposition: session
User-Agent: SIPp/Linux
Content-Length:   759


--8920nv9wiwdnnsrnia9buoyci39qsi6x
Content-Type: application/some-random-mime+xml
Content-Length: 290

<?xml version="1.0" encoding="UTF-8"?>
<xxxxxxxx>
<xxxxxxxxxxxxxxxx>
<xxxxxxxxx>yyyyyyyy</xxxxxxxxx>
<aaaaaaaaa>bbbbbbbb</aaaaaaaaa>
</xxxxxxxxxxxxxxxx>
</xxxxxxxx>
--8920nv9wiwdnnsrnia9buoyci39qsi6x
Content-Type: application/sdp
Content-Length: 479

v=0
o=- 3669370665 3669370665 IN IP4 192.168.2.2
s=application-media
t=0 0
c=IN IP4 192.168.2.2
m=audio 8000 RTP/AVP 106 96
a=rtcp:8001 IN IP4 192.168.2.2
a=sendrecv
a=rtpmap:106 AMR-WB/16000
a=fmtp:106 octet-align=0; mode-set=4
a=ptime:20
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
m=application 9000 udp XXXXX
--8920nv9wiwdnnsrnia9buoyci39qsi6x--

The command get_body_part("application/sdp", "$var(sdp)"); writes the following content in $var(sdp):

Content-Length: 479

v=0
o=- 3669370665 3669370665 IN IP4 192.168.2.2
s=application-media
t=0 0
c=IN IP4 192.168.2.2
m=audio 8000 RTP/AVP 106 96
a=rtcp:8001 IN IP4 192.168.2.2
a=sendrecv
a=rtpmap:106 AMR-WB/16000
a=fmtp:106 octet-align=0; mode-set=4
a=ptime:20
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
m=application 9000 udp XXXXX

But the expected content is:

v=0
o=- 3669370665 3669370665 IN IP4 192.168.2.2
s=application-media
t=0 0
c=IN IP4 192.168.2.2
m=audio 8000 RTP/AVP 106 96
a=rtcp:8001 IN IP4 192.168.2.2
a=sendrecv
a=rtpmap:106 AMR-WB/16000
a=fmtp:106 octet-align=0; mode-set=4
a=ptime:20
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
m=application 9000 udp XXXXX

"Content-Length: 479" is a multipart header and should be ignored. From what I understand everything after a "Content-Type:" is considered as a body.

[foucse]

I finally had some time to look into the source code, the issue comes from the file textops/textops.c:2071

    while (find_line_start("Content-Type: ", 14, &start, &len))
    {
        end = start + 14;
        len = len - 14;
        if (len > (content_type.len + 2)) {
            if (strncasecmp(end, content_type.s, content_type.len)== 0)
            {
                LM_DBG("found content type %.*s\n",
                    content_type.len, content_type.s);
                end = end + content_type.len;
                if ((*end != 13) || (*(end + 1) != 10))
                {
                    LM_ERR("no CRLF found after content type\n");
                    goto err;
                }
                end = end + 2;
                len = len - content_type.len - 2;
                body_headers_end = end;
                if (find_line_start(boundary.s, boundary.len, &end,
                    &len))
                {

Thanks to the pull "textops: Fix get_body_part() end of body headers #423" by smititelu, textops is now able to find the end of multipart headers in the simple case of just a "Content-type" header. But it is not able to handle more complex cases like this one for instance (from RFC 5621 https://tools.ietf.org/html/rfc5621#section-3.1):

      INVITE sip:conf-fact@example.com SIP/2.0
      Content-Type: multipart/mixed;boundary="boundary1"
      Content-Length: 619

      --boundary1
      Content-Type: application/sdp

      v=0
      o=alice 2890844526 2890842807 IN IP4 atlanta.example.com
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 20000 RTP/AVP 0
      a=rtpmap:0 PCMU/8000
      m=video 20002 RTP/AVP 31
      a=rtpmap:31 H261/90000

      --boundary1
      Content-Type: application/resource-lists+xml
      Content-Disposition: recipient-list

      <?xml version="1.0" encoding="UTF-8"?>
      <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
        <list>
          <entry uri="sip:bill@example.com"/>
          <entry uri="sip:randy@example.net"/>
          <entry uri="sip:joe@example.org"/>
        </list>
      </resource-lists>
      --boundary1--

                   Figure 2: SIP message carrying a body

Here "Content-Disposition: recipient-list" would be taken into the second body because the variable body_headers_end would be set just after the content type header by find_line_start("Content-Type: ", 14, &start, &len).

I think that maybe something like:

body_headers_end = find_line_start("\r\n", 14, &start, &len);

Instead of:

body_headers_end = end;

Might help. Because a \r\n should always separate headers from the body as it is specified for instance in RFC 3261 (https://tools.ietf.org/html/rfc3261#section-7) for SIP headers:

         generic-message  =  start-line
                             *message-header
                             CRLF
                             [ message-body ]
         start-line       =  Request-Line / Status-Line

I will test this solution as soon as I will have more spare time.

[miconda]

Thanks for troubleshooting further. If you test your solution and works ok, make a pull request with the patch, to be reviewed and eventually merged.

[linuxmaniac]

@foucse can you try this changes?

[miconda]

If still an issue, reopen, the patch referenced above is more than 5 months old.