[OpenSIPS-Users] Segfault crash in siptrace.c in OpenSIPs 2.2.7

[Liviu Chircu]

Hi Jon,

This sip_trace() vulnerability was reported (and solved!) before [1] 
but, for some reason, I didn't push the fix for it... will do it asap!

Cheers,

[1]: http://lists.opensips.org/pipermail/users/2018-June/039515.html

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 15.10.2018 22:49, Jon Abrams wrote:
> Howdy,
>
> I've had a few crashes on one of my instances running OpenSIPs 2.2.7 
> over the last couple of days. It appears to be an issue in the 
> siptrace.c file when a message without a call-id gets traced. For example:
>
> SIP/2.0 400 Bad Request
> Via: SIP/2.0/UDP 45.35.xx.xx:5060;branch=z9hG4bK8a78.32fc86e1.2
> Via: SIP/2.0/UDP 
> 199.242.xx.xx:5060;branch=z9hG4bK1sansay3360535464rdb10237
> From: <sip:+1984#1916424xxxx at 199.242.xx.xx>;tag=sansay3360535464rdb10237
> To: <sip:916424xxxx at 206.147.xx.xx>
> CSeq: 1 INVITE
> Error-Info: <sip:916424xxxx at 206.147.xx.xx>;cause="[line 007] SIP 
> syntax error"
> Content-Length: 0
>
> Resulting in a core file and a gdb backtrace of:
>
> (gdb) bt
> #0  0x00007f11bea1ece1 in sip_trace (msg=0x7f1244250148, 
> info=0x7ffc09a008f0)
>     at siptrace.c:1563
> #1  0x00007f11bea29084 in sip_trace_w (msg=0x7f1244250148,
>     param1=<optimized out>, param2=<optimized out>, param3=<optimized 
> out>)
>     at siptrace.c:1506
> #2  0x000000000044c518 in do_action (a=a at entry=0x7f124421f548,
>     msg=msg at entry=0x7f1244250148) at action.c:1844
> #3  0x0000000000453075 in run_action_list (msg=<optimized out>,
>     a=<optimized out>) at action.c:172
> #4  run_actions (msg=0x7f1244250148, a=<optimized out>) at action.c:137
> #5  run_top_route (a=<optimized out>, msg=msg at entry=0x7f1244250148)
>     at action.c:204
> #6  0x00007f11c0e6703f in reply_received (p_msg=0x7f1244250148)
>     at t_reply.c:1458
> #7  0x000000000047be6c in forward_reply (msg=msg at entry=0x7f1244250148)
>     at forward.c:495
> #8  0x0000000000459b82 in receive_msg (
>     buf=0x8683e0 <buf.8308> "SIP/2.0 400 Bad Request\r\nVia: 
> SIP/2.0/UDP 45.35.xx.xx:5060;branch=z9hG4bK8a78.32fc86e1.2\r\nVia: 
> SIP/2.0/UDP 
> 199.242.xx.xx:5060;branch=z9hG4bK1sansay3360535464rdb10237\r\nFrom: 
> <sip:+1984#1916424xxxx at 199."..., len=<optimized out>, 
> rcv_info=rcv_info at entry=0x7ffc09a01250,
>     existing_context=existing_context at entry=0x0) at receive.c:257
> #9  0x00000000005bded6 in udp_read_req (si=<optimized out>,
>
>
> The code at line 1552 in siptrace.c that should handle this doesn't 
> seem to be triggered:
>
>         if(parse_headers(msg, HDR_CALLID_F, 0)!=0)
>         {
>                 LM_ERR("cannot parse call-id\n");
>                 goto error;
>         }
>
> Resulting in a bad pointer dereference and segfault here at line 1563:
>         db_vals[1].val.str_val.s = msg->callid->body.s;
>
>
> If I change line 1552 to match the code in that the pv_get_callid 
> function use to check the call-id, siptrace seems to detect the 
> missing call-id fine. Here's a diff on the 2.2.7 siptrace.c
>
> --- orig/opensips-2.2.7/modules/siptrace/siptrace.c 2018-05-24 
> 16:33:57.000000000 +0000
> +++ fixed/opensips-2.2.7/modules/siptrace/siptrace.c 2018-10-15 
> 19:17:39.020664338 +0000
> @@ -1549,7 +1549,9 @@
>                 goto error;
>         }
>
> -       if(parse_headers(msg, HDR_CALLID_F, 0)!=0)
> +       if(msg->callid==NULL && ((parse_headers(msg, HDR_CALLID_F, 
> 0)==-1) ||
> + (msg->callid==NULL)) )
> +
>         {
>                 LM_ERR("cannot parse call-id\n");
>                 goto error;
>
> Again, its only an issue if sip tracing is enabled (in my case hep 
> transported to Homer) with messages missing a call-id. As far as I can 
> tell, this may still exist in the master branch, but I've only tested 
> in the 2.2.x releases.
>
> - Jon Abrams
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20181016/879a43ec/attachment-0001.html>