[asterisk-bugs] [JIRA] (ASTERISK-23340) Security Vulnerability: stack allocation of cookie headers in loop allows for unauthenticated remote denial of service attack

[Matt Jordan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-23340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan updated ASTERISK-23340:
-----------------------------------

    Target Release Version/s: 11.9.0

> Security Vulnerability: stack allocation of cookie headers in loop allows for unauthenticated remote denial of service attack
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-23340
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23340
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/HTTP
>    Affects Versions: 1.8.25.0, 11.7.0, 12.0.0
>            Reporter: Matt Jordan
>            Assignee: Richard Mudgett
>            Severity: Critical
>              Labels: Security
>      Target Release: 1.8.26.1, 1.8.27.0, 11.8.1, 11.9.0, 12.1.1
>
>
> 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}



--
This message was sent by Atlassian JIRA
(v6.2#6252)