#560 Non-printable Characters in Via Host

1.8.x
closed-fixed
core (110)
7
2012-10-31
2012-09-26
David Sanders
No

RFC 3261 doesn't allow non-printable characters (minus CRLF ending the Via header) in the host portion of the Via header.

However, OpenSIPs seems to tolerate them. PJSIP has a bug that sends gibberish for a host in the Via on some unregisters. This is tolerated by OpenSIPs on receive, but causes issues later on in the reply, which goes out with a blank host. In particular nat_traversal can't parse the reply because the host is blank.

It seems that the parsing of the Via header should be tightened to only allow printable characters as a host.

Discussion

<< < 1 2 (Page 2 of 2)
  • David Sanders
    David Sanders
    2012-10-26

    Hi Bogdan,

    The patch does correctly trigger the error_route for me, so that part works nicely.

    However, I am not able to use send_reply from the error_route without a segmentation fault.

    Here is the simple error_route I used for testing:

    error_route
    {
    send_reply("$err.rcode", "$err.rreason");
    }

    And here is the info from GDB extracted from the core dump:

    #0 0x00002b6dbe01192f in sl_send_reply_helper (msg=0x2b6dbd3e1c00, code=400, text=0x7fffee255180) at sl_funcs.c:155
    155 update_sock_struct_from_ip( &to, msg );
    (gdb) bt
    #0 0x00002b6dbe01192f in sl_send_reply_helper (msg=0x2b6dbd3e1c00, code=400, text=0x7fffee255180) at sl_funcs.c:155
    #1 0x00002b6dbdbf0311 in sig_send_reply_mod (msg=0x2b6dbd3e1c00, code=400, reason=0x7fffee255180, to_tag=0x0) at signaling.c:192
    #2 0x00002b6dbdbf072b in sig_send_reply (msg=0x2b6dbd3e1c00, str1=<value optimized out>, str2=0x2b6dbd3dbd50 "xO:\275m+") at signaling.c:149
    #3 0x0000000000411955 in do_action (a=0x2b6dbd3a5010, msg=0x2b6dbd3e1c00) at action.c:1486
    #4 0x0000000000416c85 in run_actions (msg=0x2b6dbd3e1c00, force_reset=1) at action.c:157
    #5 run_error_route (msg=0x2b6dbd3e1c00, force_reset=1) at action.c:144
    #6 0x000000000045fb60 in receive_msg (buf=0x0, len=727, rcv_info=<value optimized out>) at receive.c:115
    #7 0x00000000004b63ad in udp_rcv_loop () at udp_server.c:424
    #8 0x000000000043050b in main_loop (argc=<value optimized out>, argv=<value optimized out>) at main.c:881
    #9 main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1528
    (gdb) frame 0
    #0 0x00002b6dbe01192f in sl_send_reply_helper (msg=0x2b6dbd3e1c00, code=400, text=0x7fffee255180) at sl_funcs.c:155
    155 update_sock_struct_from_ip( &to, msg );
    (gdb) print *text
    $1 = {s = 0x782440 "bad Via header", len = 14}
    (gdb) frame 0
    #0 0x00002b6dbe01192f in sl_send_reply_helper (msg=0x2b6dbd3e1c00, code=400, text=0x7fffee255180) at sl_funcs.c:155
    155 update_sock_struct_from_ip( &to, msg );
    (gdb) l
    150 int ret;
    151
    152 if ( msg->REQ_METHOD==METHOD_ACK)
    153 return 0;
    154
    155 update_sock_struct_from_ip( &to, msg );
    156
    157 /* if that is a redirection message, dump current message set to it */
    158 if (code>=300 && code<400) {
    159 dset=print_dset(msg, &dset_len);
    (gdb) print &to
    $5 = (union sockaddr_union *) 0x7fffee2550a0
    (gdb) print to
    $6 = {s = {sa_family = 48480, sa_data = "=\275m+\000\000P\275=\275m+\000"}, sin = {sin_family = 48480, sin_port = 48445, sin_addr = {s_addr = 11117}, sin_zero = "P\275=\275m+\000"}, sin6 = {sin6_family = 48480, sin6_port = 48445,
    sin6_flowinfo = 11117, sin6_addr = {in6_u = {u6_addr8 = "P\275=\275m+\000\000\000\034>\275m+\000", u6_addr16 = {48464, 48445, 11117, 0, 7168, 48446, 11117, 0}, u6_addr32 = {3174939984, 11117, 3174964224, 11117}}},
    sin6_scope_id = 3995423008}}

    Seems like it's almost there. Thanks for the patches so far.

    - David

     
  • fix sock update if no via

     
    Attachments
  • Hi David,

    Please check the third additional patch. Let me know asap if ok, as I want to include these fixes into the new 1.8.2 release (in 2 days from now)

    Regards,
    Bogdan

     
  • David Sanders
    David Sanders
    2012-10-30

    Bogdan,

    That latest patch fixed the seg fault, but there is still a reply error.

    osips[5913]: ScriptLogging: Error occurred
    osips[5913]: ERROR:core:parse_via: <SIP/2.0/UDP 0
    osips[5913]: ERROR:core:parse_via: parsed so far:<SIP/2.0/UDP 0>
    osips[5913]: ERROR:core:get_hdr_field: bad via
    osips[5913]: INFO:core:parse_headers: bad header field
    osips[5913]: ERROR:core:parse_via: <SIP/2.0/UDP 0
    osips[5913]: ERROR:core:parse_via: parsed so far:<SIP/2.0/UDP 0>
    osips[5913]: ERROR:core:get_hdr_field: bad via
    osips[5913]: INFO:core:parse_headers: bad header field
    osips[5913]: ERROR:core:build_res_buf_from_sip_req: parse_headers failed
    osips[5913]: ERROR:sl:sl_send_reply_helper: response building failed
    osips[5913]: ERROR:signaling:sig_send_reply_mod: failed to send reply with sl module

    The first log message is from the error_route, the rest seem to come from send_reply(...). It looks like it makes it further down in sl_send_reply_helper but then trips up on parse_headers and/or build_res_buf_from_sip_req.

    - David

     
  • David Sanders
    David Sanders
    2012-10-31

    SIPp malformed via scenario

     
    Attachments
  • David Sanders
    David Sanders
    2012-10-31

    I've attached a SIPp scenario file which reproduces the latest errors I am seeing.

    Hopefully this helps you fix any remaining issues faster since we are in different time zones.

    - David

     
  • Hi David,

    I think it cannot be fixed more than this, considering that the incoming request has a bogus VIA - opensips really requires a VIA hdr (in request) in order to build a valid sip reply. So, SIP-wise, we cannot generate a reply for a request with no VIA (or broken via).

    The fixes will make opensip to behave correctly, not to crash - you can use the error route to log stuff about the received request, but sending replies will simply fail in this case.

    Let me know if I'm wrong in my thinking.

    I will upload the 3 patches on SVN and back port them to 1.8 and 1.7.

    Best regards,
    Bogdan

     
  • OK, patches are on SVN. Closing this report.

     
    • status: open-fixed --> closed-fixed
     
<< < 1 2 (Page 2 of 2)