This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Testing for Heap Overflow

From OWASP
Revision as of 14:42, 30 December 2006 by Mmeucci (talk | contribs) (Heap Overflow Testing AoC moved to Testing for Heap Overflow: naming convention)

Jump to: navigation, search

[Up]
OWASP Testing Guide v2 Table of Contents

Brief Summary


In this test we check whether a tester can make an 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 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.

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.


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. 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 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.

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. 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 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. 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 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 ). Following 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.

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


OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents

Retrieved from "https://wiki.owasp.org/index.php?title=Testing_for_Heap_Overflow&oldid=14741"