4.0
1NSchAb
1NSchAb
- No tags were found...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
146<br />
Web Application Penetration Testing<br />
process, and using fuzzing techniques.<br />
Gray Box testing<br />
When reviewing code, one must realize that there are several<br />
avenues where heap related vulnerabilities may arise. Code that<br />
seems innocuous at the first glance can actually be vulnerable<br />
under certain conditions. Since there are several variants of this<br />
vulnerability, we will cover only the issues that are predominant.<br />
Most of the time, heap buffers are considered safe by a lot of developers<br />
who do not hesitate to perform insecure operations like<br />
strcpy( ) on them. The myth that a stack overflow and instruction<br />
pointer overwrite are the only means to execute arbitrary code<br />
proves to be hazardous in case of code shown below:-<br />
int main(int argc, char *argv[])<br />
{<br />
……<br />
}<br />
vulnerable(argv[1]);<br />
return 0;<br />
int vulnerable(char *buf)<br />
{<br />
}<br />
……..<br />
HANDLE hp = HeapCreate(0, 0, 0);<br />
HLOCAL chunk = HeapAlloc(hp, 0, 260);<br />
strcpy(chunk, buf); ‘’’ Vulnerability’’’<br />
return 0;<br />
In this case, if buf exceeds 260 bytes, it will overwrite pointers in<br />
the adjacent boundary tag, facilitating the overwrite of an arbitrary<br />
memory location with 4 bytes of data once the heap management<br />
routine kicks in.<br />
Lately, several products, especially anti-virus libraries, have<br />
been affected by variants that are combinations of an integer<br />
overflow and copy operations to a heap buffer. As an example,<br />
consider a vulnerable code snippet, a part of code responsible for<br />
processing TNEF filetypes, from Clam Anti Virus 0.86.1, source<br />
file tnef.c and function tnef_message( ):<br />
string = cli_malloc(length + 1); ‘’’ Vulnerability’’’<br />
if(fread(string, 1, length, fp) != length) {‘’’ Vulnerability’’’<br />
free(string);<br />
return -1;<br />
}<br />
The malloc in line 1 allocates memory based on the value of<br />
length, which happens to be a 32 bit integer. In this particular example,<br />
length is user-controllable and a malicious TNEF file can<br />
be crafted to set length to ‘-1’, which would result in malloc( 0 ).<br />
Therefore, this malloc would allocate a small heap buffer, which<br />
would be 16 bytes on most 32 bit platforms (as indicated in malloc.h).<br />
And now, in line 2, a heap overflow occurs in the call to fread(<br />
). The 3rd argument, in this case length, is expected to be a<br />
size_t variable. But if it’s going to be ‘-1’, the argument wraps to<br />
0xFFFFFFFF, thus copying 0xFFFFFFFF bytes into the 16 byte<br />
buffer.<br />
Static code analysis tools can also help in locating heap related<br />
vulnerabilities such as “double free” etc. A variety of tools like<br />
RATS, Flawfinder and ITS4 are available for analyzing C-style<br />
languages.<br />
Tools<br />
• OllyDbg: “A windows based debugger used for analyzing buffer<br />
overflow vulnerabilities” - http://www.ollydbg.de<br />
• Spike, A fuzzer framework that can be used to explore<br />
vulnerabilities and perform length testing -<br />
http://www.immunitysec.com/downloads/SPIKE2.9.tgz<br />
• Brute Force Binary Tester (BFB), A proactive binary checker -<br />
http://bfbtester.sourceforge.net<br />
• Metasploit, A rapid exploit development and Testing frame<br />
work - http://www.metasploit.com<br />
References<br />
Whitepapers<br />
• w00w00: “Heap Overflow Tutorial” -<br />
http://www.cgsecurity.org/exploit/heaptut.txt<br />
• David Litchfield: “Windows Heap Overflows” -<br />
http://www.blackhat.com/presentations/win-usa-04/bhwin-04-litchfield/bh-win-04-litchfield.ppt<br />
Testing for Stack Overflow<br />
Summary<br />
Stack overflows occur when variable size data is copied into fixed<br />
length buffers located on the program stack without any bounds<br />
checking. Vulnerabilities of this class are generally considered to<br />
be of high severity since their exploitation would mostly permit<br />
arbitrary code execution or Denial of Service. Rarely found in interpreted<br />
platforms, code written in C and similar languages is<br />
often ridden with instances of this vulnerability. In fact almost<br />
every platform is vulnerable to stack overflows with the following<br />
notable exceptions:<br />
• J2EE – as long as native methods or system calls are not<br />
invoked<br />
• .NET – as long as /unsafe or unmanaged code is not invoked<br />
(such as the use of P/Invoke or COM Interop)<br />
• PHP – as long as external programs and vulnerable PHP<br />
extensions written in C or C++ are not called can suffer from<br />
stack overflow issues.<br />
Stack overflow vulnerabilities often allow an attacker to directly<br />
take control of the instruction pointer and, therefore, alter the<br />
execution of the program and execute arbitrary code. Besides