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-0600 | Date Closed: | 2014-03-10 15:48:29 |
Priority: | Critical | Regression? | |
Status: | Closed/Complete | Components: | 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. |