Segfault crash in siptrace.c in OpenSIPs 2.2.7

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Segfault crash in siptrace.c in OpenSIPs 2.2.7

Jon Abrams
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#[hidden email]>;tag=sansay3360535464rdb10237
To: <sip:[hidden email]>
CSeq: 1 INVITE
Error-Info: <sip:[hidden email]>;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@entry=0x7f124421f548,
    msg=msg@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@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@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@199."..., len=<optimized out>, rcv_info=rcv_info@entry=0x7ffc09a01250,
    existing_context=existing_context@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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: 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: [hidden email];tag=sansay3360535464rdb10237
To: [hidden email]
CSeq: 1 INVITE
Error-Info: [hidden email];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@entry=0x7f124421f548,
    msg=msg@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@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@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@199."..., len=<optimized out>, rcv_info=rcv_info@entry=0x7ffc09a01250,
    existing_context=existing_context@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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users