Bugs item #3571806, was opened at 2012-09-25 23:25
Message generated for change (Comment added) made by bogdan_iancu
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: Closed
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: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-31 04:41
Message:
OK, patches are on SVN. Closing this report.
----------------------------------------------------------------------
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-10-31 03:50
Message:
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
----------------------------------------------------------------------
Comment By: David Sanders (dmsanders)
Date: 2012-10-30 18:08
Message:
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
----------------------------------------------------------------------
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@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@72.215.176.13>;tag=6g8qHX7UCoq0klHC5y8FcEoEqOqGIMIl
To: <sip:19192972172@72.215.176.13>
Call-ID: DwRnHUucA06j2QdrYIFaKnrkuYpnZ0As
CSeq: 51957 REGISTER
Contact:
<sip:19192972172@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@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@72.215.176.13>;tag=6g8qHX7UCoq0klHC5y8FcEoEqOqGIMIl
To:
<sip:19192972172@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
_______________________________________________
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
