[OpenSIPS-Devel] [ opensips-Bugs-3571806 ] Non-printable Characters in Via Host

SourceForge.net noreply at sourceforge.net
Tue Oct 30 23:23:51 CET 2012


Bugs item #3571806, was opened at 2012-09-25 23:25
Message generated for change (Comment added) made by dmsanders
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3571806&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: core
Group: 1.8.x
Status: Open
Resolution: Fixed
Priority: 7
Private: No
Submitted By: David Sanders (dmsanders)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: Non-printable Characters in Via Host

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: David Sanders (dmsanders)
Date: 2012-10-30 15:23

Message:
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

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-30 03:03

Message:
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

----------------------------------------------------------------------

Comment By: David Sanders (dmsanders)
Date: 2012-10-26 13:48

Message:
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

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-26 02:51

Message:
David, 

Please see the additional patch that should solve the triggering issue
too.

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: David Sanders (dmsanders)
Date: 2012-10-22 12:26

Message:
Hi Bogdan,

I've tested the patch you provided, and it successfully detects the type of
bogus VIAs I was seeing.

However, it doesn't trigger the "error_route" I have in the OpenSIPS
script, so I'm not able to send a response to the malformed REGISTER which
had the bad VIA. This leads to the client retrying the bad message several
times.

Would it be possible for this parsing error to jump to the "error_route" so
that I can respond with a 400 to the REGISTER and stop the
retransmissions?

- David

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-21 02:47

Message:
Hi David,

Here is a patch to address this problem - I did some first testing on my
side, but give it a try too - I want to be 100% sure first it does not
break anything and second it detects the kind of bogus VIA you have.

Thanks and regards,
Bogdan

----------------------------------------------------------------------

Comment By: David Sanders (dmsanders)
Date: 2012-10-12 14:02

Message:
Here you go Bogdan.

I took the example out of the sip_trace table in our MySQL database. Thoe
host is gibberish but the port number is OK. OpenSIPS doesn't complain
about parsing errors until it is sending the 401 response.

REGISTER sip:19192972172 at 72.215.176.13:5060 SIP/2.0
Via: SIP/2.0/UDP ‰¡read   
:13611;rport;branch=z9hG4bKPjBb-CLCWWBdliGJLBdVQq5L3VvfyD3QGt
Max-Forwards: 69
From: <sip:19192972172 at 72.215.176.13>;tag=6g8qHX7UCoq0klHC5y8FcEoEqOqGIMIl
To: <sip:19192972172 at 72.215.176.13>
Call-ID: DwRnHUucA06j2QdrYIFaKnrkuYpnZ0As
CSeq: 51957 REGISTER
Contact:
<sip:19192972172 at 72.215.176.1:13611;transport=UDP;rinstance=30b85fb46d764d69>
Expires: 0
Authorization: Digest username="19192972172", realm="72.215.176.13",
nonce="50783011000007583df53abb709e661070948fd84a90f378",
uri="sip:19192972172 at 72.215.176.13:5060",
response="99c332dcb3b20051391f0e589f203983"
Content-Length:  0

                                                                           
                                                                           
                                   SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP ;received=72.215.176.1;rport=13611‰¡read
From: <sip:19192972172 at 72.215.176.13>;tag=6g8qHX7UCoq0klHC5y8FcEoEqOqGIMIl
To:
<sip:19192972172 at 72.215.176.13>;tag=9ee60da17230fa4987e498ef1c101576.0000
Call-ID: DwRnHUucA06j2QdrYIFaKnrkuYpnZ0As
CSeq: 51957 REGISTER
WWW-Authenticate: Digest realm="72.215.176.13",
nonce="507830240000075ff0bbdb222655467b236709b177002a39", stale=true
Server: Pinger.com PROXY 1.8
Content-Length: 0


----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-12 06:57

Message:
David, could you post here such a bogus VIA ?

Thanks

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3571806&group_id=232389



More information about the Devel mailing list