Difference between revisions of "Testing for Heap Overflow"

From OWASP
Jump to: navigation, search
m (Remove Alex Wheeler article since no valid link can be found.)
(16 intermediate revisions by 4 users not shown)
Line 1: Line 1:
[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
+
{{Template:OWASP Testing Guide v3}}
{{Template:OWASP Testing Guide v2}}
+
  
 
== Brief Summary ==
 
== Brief Summary ==
 
<br>
 
<br>
..here: we describe in "natural language" what we want to test.
+
In this test we check whether a tester can make a [[Heap overflow]] that exploits a memory segment.
 
<br>
 
<br>
 +
 
== Description of the Issue ==  
 
== Description of the Issue ==  
<br>
 
 
Heap is a memory segment that is used for storing dynamically allocated data and global variables. Each chunk of memory in heap consists of boundary tags that contain memory management information.  
 
Heap is a memory segment that is used for storing dynamically allocated data and global variables. Each chunk of memory in heap consists of boundary tags that contain memory management information.  
  
When a heap-based buffer is overflowed the control information in these tags is overwritten and when the heap management routine frees the buffer, a memory address overwrite take place leading to an access violation. When the overflow is executed in a controlled fashion, the vulnerability would allow an adversary to overwrite a desired memory location with a user-controlled value. Practically an attacker would be able to overwrite function pointers and various addresses stored in structures like GOT, .dtors or TEB with an address of a malicious payload.
+
When a heap-based buffer is overflowed the control information in these tags is overwritten. When the heap management routine frees the buffer, a memory address overwrite takes place leading to an access violation. When the overflow is executed in a controlled fashion, the vulnerability would allow an adversary to overwrite a desired memory location with a user-controlled value. In practice, an attacker would be able to overwrite function pointers and various addresses stored in structures like GOT, .dtors or TEB with the address of a malicious payload.
 
+
There are numerous variants of the heap overflow (heap corruption) vulnerability that can allow anything from overwriting function pointers to exploiting memory management structures for arbitrary code execution. Locating heap overflows requires closer examination in comparison to stack overflows since there are certain conditions that need to exist in code for these vulnerabilities to manifest.
+
<br>
+
  
 +
There are numerous variants of the heap overflow (heap corruption) vulnerability that can allow anything from overwriting function pointers to exploiting memory management structures for arbitrary code execution. Locating heap overflows requires closer examination in comparison to stack overflows, since there are certain conditions that need to exist in the code for these vulnerabilities to be exploitable.
  
 
== Black Box testing and example ==
 
== Black Box testing and example ==
  
The principles of black box testing for heap overflows remain the same as stack overflows. The key is to supply different and large size strings as compared to expected input.   
+
The principles of black box testing for heap overflows remain the same as stack overflows. The key is to supply as input strings that are longer than expected.   
Although the test process remains the same, the results that are visible in a debugger are significantly different. While in the case of a stack overflow an instruction pointer or SEH overwrite would be apparent, this does not hold true for a heap overflow condition. When debugging a windows program a heap overflow can appear in several different forms, the most common one being a pointer exchange taking place after the heap management routine comes into action. Shown below is a scenario that illustrates a heap overflow vulnerability.
+
Although the test process remains the same, the results that are visible in a debugger are significantly different. While in the case of a stack overflow, an instruction pointer or SEH overwrite would be apparent, this does not hold true for a heap overflow condition. When debugging a windows program, a heap overflow can appear in several different forms, the most common one being a pointer exchange taking place after the heap management routine comes into action. Shown below is a scenario that illustrates a heap overflow vulnerability.
  
  
Line 27: Line 24:
  
  
The two registers shown, EAX and ECX, can be populated with user supplied addresses which are a part of the data that is used to overflow the heap buffer. One of the address can be of a function pointer which needs to be overwritten, for example UEF( Unhandled Exception filter), and the other can be address of user supplied code that needs to be executed.   
+
The two registers shown, EAX and ECX, can be populated with user supplied addresses which are a part of the data that is used to overflow the heap buffer. One of the addresses can point to a function pointer which needs to be overwritten, for example UEF (Unhandled Exception filter), and the other can be the address of user supplied code that needs to be executed.   
  
When MOV instructions shown in the left pane are executed, the overwrite takes place and user supplied code gets executed when the function is called.
+
When the MOV instructions shown in the left pane are executed, the overwrite takes place and, when the function is called, user supplied code gets executed.
As mentioned previously, other methods of testing such vulnerabilities include reverse engineering the application binaries, which is a complex and tedious process, and using Fuzzing techniques.
+
As mentioned previously, other methods of testing such vulnerabilities include reverse engineering the application binaries, which is a complex and tedious process, and using fuzzing techniques.
  
 
== Gray Box testing and example ==  
 
== Gray Box testing and example ==  
  
When reviewing code one must realize that there exist several avenues where heap related vulnerabilities may arise. Code that may seem to be innocuous at the first glance can prove to be vulnerable when certain conditions occur. Since there are several variants of this vulnerability, we will cover issues that are predominant.
+
When reviewing code, one must realize that there are several avenues where heap related vulnerabilities may arise. Code that seems innocuous at the first glance can actually be vulnerable under certain conditions. Since there are several variants of this vulnerability, we will cover only the issues that are predominant.
Most of the time heap buffers are considered safe by a lot of developers who do not hesitate to perform insecure operations like strcpy( ) on them. The myth, that a stack overflow and instruction pointer overwrite are the only means to execute arbitrary code, proves to be hazardous in case of code shown below:-
+
Most of the time, heap buffers are considered safe by a lot of developers who do not hesitate to perform insecure operations like strcpy( ) on them. The myth that a stack overflow and instruction pointer overwrite are the only means to execute arbitrary code proves to be hazardous in case of code shown below:-
  
 
<pre>
 
<pre>
Line 62: Line 59:
 
</pre>
 
</pre>
  
In this case if buf exceeds 260 bytes, it will overwrite pointers in the adjacent boundary tag facilitating overwrite of an arbitrary memory location with 4 bytes of data once the heap management routine kicks in.
+
In this case, if buf exceeds 260 bytes, it will overwrite pointers in the adjacent boundary tag, facilitating the overwrite of an arbitrary memory location with 4 bytes of data once the heap management routine kicks in.
  
Lately several products, especially anti-virus libraries, have been affected by variants that are combinations of an integer overflow and copy operations to a heap buffer. As an example consider a vulnerable code snippet, a part of code responsible for processing TNEF filetypes, from Clam Anti Virus 0.86.1, source file tnef.c and function tnef_message( ):  
+
Lately, several products, especially anti-virus libraries, have been affected by variants that are combinations of an integer overflow and copy operations to a heap buffer. As an example, consider a vulnerable code snippet, a part of code responsible for processing TNEF filetypes, from Clam Anti Virus 0.86.1, source file tnef.c and function tnef_message( ):  
  
 
<pre>
 
<pre>
Line 74: Line 71:
 
</pre>
 
</pre>
  
The malloc in line 1 allocates memory based on the value of length, which happens to be a 32 bit integer. In this particular example length is user controllable and a malicious TNEF file can be crafted to set length to ‘-1’, which would result in malloc( 0 ). Following this malloc would allocate a small heap buffer, which would be 16 bytes on most 32 bit platforms (as indicated in malloc.h).   
+
The malloc in line 1 allocates memory based on the value of length, which happens to be a 32 bit integer. In this particular example, length is user-controllable and a malicious TNEF file can be crafted to set length to ‘-1’, which would result in malloc( 0 ). Therefore, this malloc would allocate a small heap buffer, which would be 16 bytes on most 32 bit platforms (as indicated in malloc.h).   
  
And now in line 2 heap overflow occurs in the call to fread( ).  The 3rd argument, in this case length, is expected to be a size_t variable. But if it’s going to be ‘-1’, the argument wraps to 0xFFFFFFFF and there by copying 0xFFFFFFFF bytes into the 16 byte buffer.   
+
And now, in line 2, a heap overflow occurs in the call to fread( ).  The 3rd argument, in this case length, is expected to be a size_t variable. But if it’s going to be ‘-1’, the argument wraps to 0xFFFFFFFF, thus copying 0xFFFFFFFF bytes into the 16 byte buffer.   
 
+
Static code analysis tools can also help in locating heap related vulnerabilities such as “double free” etc. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages.
+
  
 +
Static code analysis tools can also help in locating heap related vulnerabilities such as “double free” etc. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages.
  
 
==References==
 
==References==
 
'''Whitepapers'''<br>
 
'''Whitepapers'''<br>
* w00w00: "Heap Overflow Tutorial" - <u>http://www.w00w00.org/files/articles/heaptut.txt</u>
+
* w00w00: "Heap Overflow Tutorial" - http://www.cgsecurity.org/exploit/heaptut.txt
* David Litchfield: "Windows Heap Overflows" - <u>http://www.blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/bh-win-04-litchfield.ppt</u>
+
* David Litchfield: "Windows Heap Overflows" - http://www.blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/bh-win-04-litchfield.ppt
* Alex wheeler: "Clam Anti-Virus Multiple remote buffer overflows" - <u>http://www.rem0te.com/public/images/clamav.pdf</u>
+
  
 
'''Tools'''<br>
 
'''Tools'''<br>
* OllyDbg: "A windows based debugger used for analyzing buffer overflow vulnerabilities" - <u>http://www.ollydbg.de/</u>
+
* OllyDbg: "A windows based debugger used for analyzing buffer overflow vulnerabilities" - http://www.ollydbg.de
* Spike, A fuzzer framework that can be used to explore vulnerabilities and perform length testing - <u>http://www.immunitysec.com/downloads/SPIKE2.9.tgz</u>
+
* Spike, A fuzzer framework that can be used to explore vulnerabilities and perform length testing - http://www.immunitysec.com/downloads/SPIKE2.9.tgz
* Brute Force Binary Tester (BFB), A proactive binary checker - <u>http://bfbtester.sourceforge.net/</u>
+
* Brute Force Binary Tester (BFB), A proactive binary checker - http://bfbtester.sourceforge.net
* Metasploit, A rapid exploit development and Testing frame work - <u>http://www.metasploit.com/projects/Framework/</u>
+
 
 +
 
 +
[[Category:FIXME|link not working
 +
 
 +
* Metasploit, A rapid exploit development and Testing frame work - http://www.metasploit.com/projects/Framework
 
* Stack [Varun Uppal (varunuppal81@gmail.com)]
 
* Stack [Varun Uppal (varunuppal81@gmail.com)]
  
Go back to [[Testing_for_buffer_overflow]]
 
  
{{Category:OWASP Testing Project AoC}}
+
]]

Revision as of 12:11, 6 November 2012

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here

Contents


Brief Summary


In this test we check whether a tester can make a Heap overflow that exploits a memory segment.

Description of the Issue

Heap is a memory segment that is used for storing dynamically allocated data and global variables. Each chunk of memory in heap consists of boundary tags that contain memory management information.

When a heap-based buffer is overflowed the control information in these tags is overwritten. When the heap management routine frees the buffer, a memory address overwrite takes place leading to an access violation. When the overflow is executed in a controlled fashion, the vulnerability would allow an adversary to overwrite a desired memory location with a user-controlled value. In practice, an attacker would be able to overwrite function pointers and various addresses stored in structures like GOT, .dtors or TEB with the address of a malicious payload.

There are numerous variants of the heap overflow (heap corruption) vulnerability that can allow anything from overwriting function pointers to exploiting memory management structures for arbitrary code execution. Locating heap overflows requires closer examination in comparison to stack overflows, since there are certain conditions that need to exist in the code for these vulnerabilities to be exploitable.

Black Box testing and example

The principles of black box testing for heap overflows remain the same as stack overflows. The key is to supply as input strings that are longer than expected. Although the test process remains the same, the results that are visible in a debugger are significantly different. While in the case of a stack overflow, an instruction pointer or SEH overwrite would be apparent, this does not hold true for a heap overflow condition. When debugging a windows program, a heap overflow can appear in several different forms, the most common one being a pointer exchange taking place after the heap management routine comes into action. Shown below is a scenario that illustrates a heap overflow vulnerability.


Heap overflow vulnerability.gif


The two registers shown, EAX and ECX, can be populated with user supplied addresses which are a part of the data that is used to overflow the heap buffer. One of the addresses can point to a function pointer which needs to be overwritten, for example UEF (Unhandled Exception filter), and the other can be the address of user supplied code that needs to be executed.

When the MOV instructions shown in the left pane are executed, the overwrite takes place and, when the function is called, user supplied code gets executed. As mentioned previously, other methods of testing such vulnerabilities include reverse engineering the application binaries, which is a complex and tedious process, and using fuzzing techniques.

Gray Box testing and example

When reviewing code, one must realize that there are several avenues where heap related vulnerabilities may arise. Code that seems innocuous at the first glance can actually be vulnerable under certain conditions. Since there are several variants of this vulnerability, we will cover only the issues that are predominant. Most of the time, heap buffers are considered safe by a lot of developers who do not hesitate to perform insecure operations like strcpy( ) on them. The myth that a stack overflow and instruction pointer overwrite are the only means to execute arbitrary code proves to be hazardous in case of code shown below:-

int main(int argc, char *argv[])
	{
		……

		vulnerable(argv[1]);		                                 
		return 0;
	}


	int vulnerable(char *buf)
	{
		
		HANDLE hp = HeapCreate(0, 0, 0);		
		
		HLOCAL chunk = HeapAlloc(hp, 0, 260);

		strcpy(chunk, buf);  ''' Vulnerability''' 
                         
                          …….. 

		return 0;
	}

In this case, if buf exceeds 260 bytes, it will overwrite pointers in the adjacent boundary tag, facilitating the overwrite of an arbitrary memory location with 4 bytes of data once the heap management routine kicks in.

Lately, several products, especially anti-virus libraries, have been affected by variants that are combinations of an integer overflow and copy operations to a heap buffer. As an example, consider a vulnerable code snippet, a part of code responsible for processing TNEF filetypes, from Clam Anti Virus 0.86.1, source file tnef.c and function tnef_message( ):

string = cli_malloc(length + 1); ''' Vulnerability'''
if(fread(string, 1, length, fp) != length) {''' Vulnerability'''
free(string);
return -1;
}

The malloc in line 1 allocates memory based on the value of length, which happens to be a 32 bit integer. In this particular example, length is user-controllable and a malicious TNEF file can be crafted to set length to ‘-1’, which would result in malloc( 0 ). Therefore, this malloc would allocate a small heap buffer, which would be 16 bytes on most 32 bit platforms (as indicated in malloc.h).

And now, in line 2, a heap overflow occurs in the call to fread( ). The 3rd argument, in this case length, is expected to be a size_t variable. But if it’s going to be ‘-1’, the argument wraps to 0xFFFFFFFF, thus copying 0xFFFFFFFF bytes into the 16 byte buffer.

Static code analysis tools can also help in locating heap related vulnerabilities such as “double free” etc. A variety of tools like RATS, Flawfinder and ITS4 are available for analyzing C-style languages.

References

Whitepapers

Tools