[Home]

Summary:ASTERISK-08917: Single SIP packet can reproducibly crash Asterisk
Reporter:rdaigle (rdaigle)Labels:
Date Opened:2007-03-01 15:30:22.000-0600Date Closed:2007-03-06 11:26:21.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) fix9182.diff
Description:A SIP message where the Request-Line portion is truncated to not include URI or SIP-version reproducibly causes the Asterisk server to crash.  For example:  "REGISTER\r\n<followed by all required SIP headers>".  Minimally, "REGISTER\r\nCSeq: 1\r\n\r\n" will trip it.

Analysis below:  (the key appears to be that caller of determine_firstline_parts() doesn't check for error)


static int sipsock_read(int *id, int fd, short events, void *ignore)
{
...
    memset(&req, 0, sizeof(req));
...
    parse_request(&req);    <---- condition req->rlPart2 not set  
here (continues to be null)
...
        if (handle_request(p, &req, &sin, &recount, &nounlock) ==  
-1) {  <------- req->rlPart2 is referenced down here.
}

static void parse_request(struct sip_request *req)
{
...
    /* Split up the first line parts */
    determine_firstline_parts(req);  <---- no error checking.
}

static int determine_firstline_parts( struct sip_request *req )
{
    char *e, *cmd;
    int len;

    cmd = ast_skip_blanks(req->header[0]);
    if (!*cmd)
        return -1;
    req->rlPart1 = cmd;
    e = ast_skip_nonblanks(cmd);
    /* Get the command */
    if (*e)
        *e++ = '\0';
    e = ast_skip_blanks(e);
    if ( !*e )
        return -1;    <------ req->rlPar2 is never set.
...
}


If we follow the REGISTER command after sipsock_read, we get:

static int handle_request(struct sip_pvt *p, struct sip_request *req,  
struct sockaddr_in *sin, int *recount, int *nounlock)
{
...
    cmd = req->rlPart1;
    e = req->rlPart2;
...
    case SIP_REGISTER:
        res = handle_request_register(p, req, debug, ignore, sin,  
e);  <----- e is the null field.
...
}

static int handle_request_register(struct sip_pvt *p, struct  
sip_request *req, int debug, int ignore, struct sockaddr_in *sin,  
char *e)
{
...
    if ((res = register_verify(p, sin, req, e, ignore)) < 0)
...
}

static int register_verify(struct sip_pvt *p, struct sockaddr_in  
*sin, struct sip_request *req, char *uri, int ignore)
{
...
    /* Terminate URI */
    t = uri;
    while(*t && (*t > 32) && (*t != ';'))    <---- BOOM.  uri is null.
        t++;
    *t = '\0';
...
}



****** ADDITIONAL INFORMATION ******

If you have questions, we would be happy to help.  Once you have had
a chance to fix the problem, let us know so that we can release an
advisory.

Regards,
Mu Security Research Team
Comments:By: Clod Patry (junky) 2007-03-02 01:12:36.000-0600

I cant reproduce this with:

<--- SIP read from 127.0.0.1:5060 --->
REGISTER
CSeq: 1


<------------->
--- (2 headers 0 lines) ---
[Mar  2 02:11:46] DEBUG[15501]: chan_sip.c:14771 sipsock_read: Invalid SIP message - rejected , no callid, len 22



but:

Index: channels/chan_sip.c
===================================================================
--- channels/chan_sip.c (revision 57457)
+++ channels/chan_sip.c (working copy)
@@ -5551,7 +5551,7 @@
       memset(req, 0, sizeof(*req));
        req->method = sipmethod;
       req->header[0] = req->data;
-       snprintf(req->header[0], sizeof(req->data), "%s %s SIP/2.0\r\n", sip_methods[sipmethod].text, recip);
+       snprintf(req->header[0], sizeof(req->data), "%s\r\n", sip_methods[sipmethod].text);
       req->len = strlen(req->header[0]);
       req->headers++;
       return 0;


will make remote * crashing.


By: Clod Patry (junky) 2007-03-02 02:12:41.000-0600

let me watcha think about that fix.
By: Joshua C. Colp (jcolp) 2007-03-02 10:56:21.000-0600

The attached patch is incorrect. A fix will soon be available.
By: Joshua C. Colp (jcolp) 2007-03-02 11:09:36.000-0600

Please try 1.2 as of revision 57475, 1.4 as of revision 57477, and trunk as of revision 57478 and report back.
By: Russell Bryant (russell) 2007-03-02 14:23:03.000-0600

Even if your tests are successful, please do *not* send any public advisory yet.
By: rdaigle (rdaigle) 2007-03-05 15:51:01.000-0600

Please review the text of the following advisory I would like to publish.  Any comments are welcome.  Also, let me know when would be appropriate to release.

======================

NULL Pointer Vulnerability in Asterisk  [MU-2006-03-05]
<Month Day, Year - date advisory released>
March xx, 2006

http://labs.musecurity.com/advisories.html

Affected Products/Versions:

Asterisk releases 1.2.15 and 1.4.0

Product Overview:

http://www.asterisk.org/

"Asterisk is the most popular and extensible open source telephone system in th\
e world, offering flexibility, functionality and features not available in adva\
nced, high-end (high-cost) proprietary business systems. Asterisk is a complete\
IP PBX (private branch exchange) for businesses, and can be downloaded for fre\
e."


Vulnerability Details:

Asterisk crashes when handed an otherwise valid request message but with no
URI and no SIP-version in the request-line of the message.  For example,
"REGISTER\r\n <other valid SIP headers>".  The crash is due to a null pointer
dereference, and does not appear to be otherwise exploitable.


Vendor Response / Solution:

Update to releases 1.2.16, 1.4.1 or trunk revision 57478 or greater.  Available from http://www.asterisk.org

History:
March 1, 2006 - First contact with vendor
March 2, 2006 - Vendor acknowledges vulnerability
March x, 2006 - Advisory released


Credit:

This vulnerability was discovered by the Mu Security research team.

http://labs.musecurity.com/pgpkey.txt

Mu Security offers a new class of security analysis system, delivering a
rigorous and streamlined methodology for verifying the robustness and security
readiness of any IP-based product or application. Founded by the pioneers of
intrusion detection and prevention technology, Mu Security is backed by
preeminent venture capital firms that include Accel Partners, Benchmark
Capital and DAG Ventures. The company is headquartered in Sunnyvale, CA. For
more information, visit the company's website at http://www.musecurity.com.


By: Clod Patry (junky) 2007-03-05 15:53:56.000-0600

im not sure we should explain how to exploit that issue.
Just saying a bug in the sip stack is enuf, no?
By: Jason Parker (jparker) 2007-03-05 16:07:39.000-0600

There have been new releases of both 1.2 and 1.4.  It may be best to mention that only versions 1.2.15 and 1.4.0 and below are affected (the fix was put in before 1.2.16 and 1.4.1 were released).
By: Serge Vecher (serge-v) 2007-03-05 16:09:07.000-0600

rdaigle: I've just updated the verbage regarding the releases, we recommend the community to install Asterisk from the tarballs, not svn. Thanks for response back; you didn't state it explicitly, but the issue is fixed in 1.2.16 / 1.4.1, right?
By: Russell Bryant (russell) 2007-03-06 11:26:20.000-0600

The security report you have posted looks fine, pending one minor change noted below.  Also, feel free to release your report whenever you are ready now that we have releases already made.

1) When noting the affected versions, be sure to note that it is 1.2.15, 1.4.0, as well as any earlier version.