[Home]

Summary:ASTERISK-23340: Security Vulnerability: stack allocation of cookie headers in loop allows for unauthenticated remote denial of service attack
Reporter:Matt Jordan (mjordan)Labels:Security
Date Opened:2014-02-21 09:36:22.000-0600Date Closed:2014-03-10 15:48:29
Priority:CriticalRegression?
Status:Closed/CompleteComponents:Core/HTTP
Versions:1.8.25.0 11.7.0 12.0.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:From the vulnerability reporter:

{quote}
We are still writing the advisory but I will provide the gist of the problem below so you can start looking into it.
It's really a simple bug.

The parsing of HTTP Cookie header is done as seen below:
{quote}

[http://svnview.digium.com/svn/asterisk/trunk/main/http.c?view=markup&pathrev=394901]

{noformat}
854 /* get cookie from Request headers */
855 structast_variable*ast_http_get_cookies(structast_variable*headers)
856 {
857 structast_variable*v,*cookies=NULL;
858
859 for(v=headers;v;v=v->next){
860 if(!strcasecmp(v->name,"Cookie")){
861 char*tmp=ast_strdupa(v->value);
862 if(cookies){
863 ast_variables_destroy(cookies);
864 }
865
866 cookies=parse_cookies(tmp);
867 }
868 }
869 returncookies;
870 }
{noformat}

{quote}
Note that multiple Cookie headers are supported and each of them is parsed within the loop.
A temporary copy of the the header's content is made in line 861 before parsing the
actual (name, value) pairs with parse_cookies in line 866.

The copy is made using ast_strdupa() which is just a wrapper for alloca() + memcpy() :
{quote}

{noformat}
#define ast_strdupa(s) \
(__extension__ \
({ \
const char *__old = (s); \
size_t __len = strlen(__old) + 1; \
char *__new = __builtin_alloca(__len); \
memcpy (__new, __old, __len); \
__new; \
}))
#endif
{noformat}

{quote}
alloca() simple moves the stack pointer to make room in the stack for a len bytes
[http://man7.org/linux/man-pages/man3/alloca.3.html]

Since the call to ast_strdupa() is made within a loop for each Cookie header found
and the number of Coookie headers is not bounded, a remote attacker could send
an HTTP POST request with as many Cookie headers as necessary to make the thread's
stack grow and overlap with another thread's stack.

The immediate obvious effect of this is a remote denial of service via an
unauthenticated HTPP POST request.

Besides that, we have explored the possibility of using this bug for remote code execution
with techniques similar to those explained here:

http://blog.exodusintel.com/tag/asterisk-exploit/

The relevant difference in our case is that the alloca() is followed by a memcpy() and
on Linux or other glibc platforms each thread created with pthread_create() gets a
no-rw guard page allocated by default as explained here:

http://man7.org/linux/man-pages/man3/pthread_attr_setguardsize.3.html

So far we have not found anyway to exploit this vulnerability for remote code execution on
platforms where glibc pthreads is used with default settings but we do not yet discard
the possibility. Exploitation on platforms where no guard page is allocated to prevent
threads from overlapping each other's stack should be relatively easy.

Attached is a Python script that will help you to repro the problem agsinst an Asterisk
server runnign on localhost.

Please let us know when you are able to repro and give us an estimate date for the
release of a fix and a corresponding security advisory.

Should you want to credit the finder of the bug please use the following:

Found by Lucas Molas, researcher at Programa STIC, FundaciĆ³n Dr. Manuel Sadosky,
Buenos Aires, Argentina


regards,

-ivan
{quote}



Comments:By: Matt Jordan (mjordan) 2014-02-21 09:40:51.313-0600

This one is old: been around since r215070.

By: Richard Mudgett (rmudgett) 2014-03-10 14:04:05.847-0500

The issue is resolved as fixed.  JIRA currently doesn't request the resolution status so it just states as unresolved.