Testing for Heap Overflow - Revision history

Andrew Muller at 16:31, 31 July 2014

2014-07-31T16:31:13Z

Jane O'Connor: Final edit

2014-05-19T10:30:48Z

Final edit

Mmeucci at 17:32, 9 March 2014

2014-03-09T17:32:21Z

David Fern: Remove Alex Wheeler article since no valid link can be found.

2012-11-06T17:11:30Z

Remove Alex Wheeler article since no valid link can be found.

David Fern: Updated Heap Overflow tutorial URL

2012-11-06T17:10:14Z

Updated Heap Overflow tutorial URL

KirstenS: /* References */

2009-02-09T21:08:32Z

‎References

KirstenS: /* References */

2009-02-09T21:07:32Z

‎References

KirstenS: /* Description of the Issue */

2009-02-09T21:03:16Z

‎Description of the Issue

KirstenS: /* Gray Box testing and example */

2008-12-14T01:57:54Z

‎Gray Box testing and example

KirstenS: /* Description of the Issue */

2008-12-14T01:55:40Z

‎Description of the Issue

@@ Line 1: / Line 1: @@
 {{Template:OWASP Testing Guide v4}}
-== Brief Summary ==
+== Summary ==
 In this test the penetration tester checks whether a they can make a [[Heap overflow]] that exploits a memory segment.
 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.
@@ Line 14: / Line 13: @@
 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 ===
 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.
@@ Line 29: / Line 29: @@
-== Gray Box testing and example ==
+=== Gray Box testing ===
 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.
@@ Line 85: / Line 85: @@
-==References==
+==Tools==
 * 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 - http://www.immunitysec.com/downloads/SPIKE2.9.tgz
 * Brute Force Binary Tester (BFB), A proactive binary checker - http://bfbtester.sourceforge.net
-[[Category:FIXME|link not working
-* Metasploit, A rapid exploit development and Testing frame work - http://www.metasploit.com/projects/Framework
+==References==
-* Stack [Varun Uppal (varunuppal81@gmail.com)]
+'''Whitepapers'''<br>
-]]
+* w00w00: "Heap Overflow Tutorial" - http://www.cgsecurity.org/exploit/heaptut.txt

@@ Line 2: / Line 2: @@
 == Brief Summary ==
-<br>
+In this test the penetration tester checks whether a they can make a [[Heap overflow]] that exploits a memory segment.
-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.
+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.
-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:-
@@ Line 58: / Line 60: @@
+	}
 </pre>
 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( ):
@@ Line 70: / Line 74: @@
+}
 </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 ). 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==
@@ Line 81: / Line 89: @@
 * w00w00: "Heap Overflow Tutorial" - http://www.cgsecurity.org/exploit/heaptut.txt
 * David Litchfield: "Windows Heap Overflows" - http://www.blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/bh-win-04-litchfield.ppt
 '''Tools'''<br>
@@ Line 89: / Line 98: @@
 [[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)]
 ]]

← Older revision		Revision as of 17:32, 9 March 2014
Line 1:		Line 1:
−	{{Template:OWASP Testing Guide v3}}	+	{{Template:OWASP Testing Guide v4}}

	== Brief Summary ==		== Brief Summary ==

← Older revision		Revision as of 17:11, 6 November 2012
Line 89:		Line 89:

	[[Category:FIXME\|link not working		[[Category:FIXME\|link not working
−
−	* Alex wheeler: "Clam Anti-Virus Multiple remote buffer overflows" - http://www.rem0te.com/public/images/clamav.pdf

	* Metasploit, A rapid exploit development and Testing frame work - http://www.metasploit.com/projects/Framework		* Metasploit, A rapid exploit development and Testing frame work - http://www.metasploit.com/projects/Framework

@@ Line 79: / Line 79: @@
 ==References==
 '''Whitepapers'''<br>
-* w00w00: "Heap Overflow Tutorial" - http://www.w00w00.org/files/articles/heaptut.txt
+* w00w00: "Heap Overflow Tutorial" - http://www.cgsecurity.org/exploit/heaptut.txt
 * David Litchfield: "Windows Heap Overflows" - http://www.blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/bh-win-04-litchfield.ppt

@@ Line 86: / Line 86: @@
 * 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 - http://bfbtester.sourceforge.net
@@ Line 94: / Line 92: @@
 * Alex wheeler: "Clam Anti-Virus Multiple remote buffer overflows" - http://www.rem0te.com/public/images/clamav.pdf
 ]]