# Author: Flavio do Carmo Junior aka waKKu
# URL: Author’s Webpage
# Date: February 16, 2011
# Category: Exploiting, Programming, Security, Vulnerability Analysis
Welcome back, goodfella ;)
This is another post in “Vulnerability Analysis” category, but at this time, this is one of our (DcLabs) 0-days.
2. Triggering the bug
One of DcLabs members, ipax, using a fuzzer noticed that when sending a big buffer and using the “HEAD” HTTP Method the software crashed with a segfault signal.
He then asked me to take a look and, some time later, here we are ;). Ok, first thing to do is download a copy of the software and (God bless open source) compile it with debugging symbols, then running our “trigger” again, we were able to identify the crash:
# --- gdb output --- MANAGER: 1 jobs in ACCEPTOR->PARSER queue errorer #1 has job (status = 400) (.errors/400.html) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1208023360 (LWP 14222)] logger_th (arg=Cannot access memory at address 0xa30300c ) at main.c:383 383 printf("logger #%d: '%s' LOGGED [%d]\n", id, job->hdr.request_line, job->status); # --- gdb output ---
The flaw happened at function logger_th(), something overwrote its argument address, as seen in (logger_th (arg=Cannot access memory at address 0xa30300c)) gdb message.
3. Hunting down a vulnerability
Read the rest of this entry »