Details
Description
From the vulnerability reporter:
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:
http://svnview.digium.com/svn/asterisk/trunk/main/http.c?view=markup&pathrev=394901
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 }
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() :
#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
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.htmlSince 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, Argentinaregards,
-ivan
This one is old: been around since r215070.