{"id":9839,"date":"2013-07-02T15:00:41","date_gmt":"2013-07-02T13:00:41","guid":{"rendered":"https:\/\/www.corelan.be\/?p=9839"},"modified":"2026-03-22T10:12:32","modified_gmt":"2026-03-22T09:12:32","slug":"root-cause-analysis-integer-overflows","status":"publish","type":"post","link":"https:\/\/www.corelan.be\/index.php\/2013\/07\/02\/root-cause-analysis-integer-overflows\/","title":{"rendered":"Root Cause Analysis – Integer Overflows"},"content":{"rendered":"\n

Foreword<\/h3>\n

Over the past few years, Corelan Team has received many exploit related questions, including "I have found a bug and I don't seem to control EIP, what can I do ?"; "Can you write a tutorial on heap overflows" or "what are Integer overflows".<\/p>\n

In this article, Corelan Team member Jason Kratzer (pyoor) tries to answer some of these questions in a very practical, hands-on way.  He went to great lengths to illustrate the process of finding a bug, taking the crash information and reverse engineering the crash context to identifying the root cause of the bug, to finally discussing multiple ways to exploit the bug.  Of course, most - if not all - of the techniques in this document were discovered many years ago, but I'm sure this is one of the first (public) articles that shows you how to use them in a real life scenario, with a real application.  Although the techniques mostly apply to Windows XP, we believe it is required knowledge, necessary before looking at newer versions of the Windows Operating system and defeating modern mitigation techniques.<\/p>\n

enjoy !<\/p>\n

- corelanc0d3r<\/p>\n

 <\/p>\n

Introduction<\/h3>\n

In my previous article<\/a>, we discussed the process used to evaluate a memory corruption bug that I had identified in a recently patched version of KMPlayer.  With the crash information generated by this bug we were able to step through the crash, identify the root cause of our exception, and determine exploitability.  In doing so, we were able to identify 3 individual methods that could potentially be used for exploitation.  This article will serve as a continuation of the series with the intention of building upon some of the skills we discussed during the previous \u201cRoot Cause Analysis\u201d article.  I highly recommend that if you have not done so already, please review the contents of that article (located here<\/a>) before proceeding.<\/p>\n

For the purpose of this article, we\u2019ll be analyzing an integer overflow that I had identified in the GOM Media Player software developed by GOM Labs.  This bug affects GOM Media Player 2.1.43 and was reported to the GOM Labs development team on November 19, 2012.  A patch was released to mitigate this issue on December 12, 2012.<\/p>\n

As with our previous bug, I had identified this vulnerability by fuzzing the MP4\/QT file formats using the Peach Framework (v2.3.9).  In order to reproduce this issue, I have provided a bare bones fuzzing template (Peach PIT) which specifically targets the vulnerable portion of the MP4\/QT file format.  You can find a copy of that Peach PIT here.  The vulnerable version of GOM player can be found here.<\/p>\n

 <\/p>\n

 <\/p>\n

<\/a>Analyzing the Crash Data<\/h3>\n

Let\u2019s begin by taking a look at the file, LocalAgent_StackTrace.txt, which was generated by Peach at crash time.  I\u2019ve included the relevant portions below:<\/p>\n

 <\/p>\n

(cdc.5f8): Access violation - code c0000005 (first chance)\nr\neax=00000028 ebx=0000004c ecx=0655bf60 edx=00004f44 esi=06557fb4 edi=06555fb8\neip=063b4989 esp=0012bdb4 ebp=06557f00 iopl=0         nv up ei pl nz na pe nc\ncs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00210206\nGSFU!DllUnregisterServer+0x236a9:\n063b4989 891481          mov     dword ptr [ecx+eax*4],edx ds:0023:0655c000=????????<\/span><\/strong>\n\nkb\nChildEBP RetAddr  Args to Child              \nWARNING: Stack unwind information not available. Following frames may be wrong.\n0012bdc0 063b65eb 064dcda8 06555fb8 0652afb8 GSFU!DllUnregisterServer+0x236a9\n0012bdd8 063b8605 064dcda8 06555fb8 0652afb8 GSFU!DllUnregisterServer+0x2530b\n0012be00 063b8a85 064dcda8 0652afb8 0652afb8 GSFU!DllUnregisterServer+0x27325\n0012be18 063b65eb 064dcda8 0652afb8 06510fb8 GSFU!DllUnregisterServer+0x277a5\n0012be30 063b8605 064dcda8 0652afb8 06510fb8 GSFU!DllUnregisterServer+0x2530b\n0012be58 063b8a85 064dcda8 06510fb8 06510fb8 GSFU!DllUnregisterServer+0x27325\n0012be70 063b65eb 064dcda8 06510fb8 06500fb8 GSFU!DllUnregisterServer+0x277a5\n<...truncated...>\n\nINSTRUCTION_ADDRESS:0x00000000063b4989\nINVOKING_STACK_FRAME:0\nDESCRIPTION:User Mode Write AV\nSHORT_DESCRIPTION:WriteAV\nCLASSIFICATION:EXPLOITABLE\nBUG_TITLE:Exploitable - User Mode Write AV starting at GSFU!DllUnregisterServer+0x00000000000236a9 (Hash=0x1f1d1443.0x00000000)<\/span><\/strong>\nEXPLANATION:User mode write access violations that are not near NULL are exploitable.<\/pre>\n
(You can download the complete Peach crash data here)<\/p>\n
As we can see here, we\u2019ve triggered a write access violation by attempting to write the value of edx to the location pointed at by [ecx+eax*4].  This instruction fails of course because the location [ecx+eax*4] points to an inaccessible region of memory. (0655c000=????????)<\/p>\n
Since we do not have symbols for this application, the stack trace does not provide us with any immediately evident clues as to the cause of our exception.<\/p>\n
Furthermore, we can also see that !exploitable has made the assumption that this crash is exploitable due to the fact that the faulting instruction attempts to write data to an out of bounds location and that location is not near null.  It makes this distinction because a location that is near null may be indicative of a null pointer dereference and these types of bugs are typically not exploitable (though not always<\/a>). Let\u2019s try and determine if !exploitable is in fact, correct in this assumption.<\/p>\n
 <\/p>\n
 <\/p>\n
<\/a>Identifying the Cause of Exception<\/h3>\n
<\/a>Page heap<\/h4>\n
Before we begin, there\u2019s something very important that we must discuss.  Take a look at the bare bones Peach PIT I\u2019ve provided; particularly the Agent configuration beginning at line 55.<\/p>\n
<Agent name="LocalAgent">\n  <Monitor class="debugger.WindowsDebugEngine">\n    <Param name="CommandLine" value="C:\\Program Files\\GRETECH\\GomPlayer\\GOM.EXE &quot;C:\\fuzzed.mov&quot;" \/>\n    <Param name="StartOnCall" value="GOM.EXE" \/>\n  <\/Monitor>\n  <Monitor class="process.PageHeap">\n    <Param name="Executable" value="GOM.EXE"\/>\n  <\/Monitor>\n<\/Agent><\/pre>\n
Using this configuration, I\u2019ve defined the primary monitor as the \u201cWindowsDebugEngine\u201d which uses PyDbgEng, a wrapper for the WinDbg engine dbgeng.dll, in order to monitor the process.  This is typical of most Peach fuzzer configurations under windows.  However, what\u2019s important to note here is the second monitor, \u201cprocess.PageHeap\u201d.  This monitor enables full page heap verification by using the Microsoft Debugging tool, GFlags (Global Flags Editor).  In short, GFlags is a utility that is packaged with the Windows SDK, and enables users to more easily troubleshoot potential memory corruption issues.  There are a number of configuration options available with GFlags.  For the purpose of this article, we\u2019ll only be discussing 2: standard and full page heap verification.<\/p>\n
When using page heap verification, a special page header prefixes each heap chunk.  The image below displays the structure of a standard (allocated) heap chunk and the structure of an (allocated) heap chunk with page heap enabled.<\/p>\n
\"RCA-Integer-Overflow-6\"<\/a> <\/strong><\/p>\n
\n
This information can also be extracted by using the following display types variables:<\/p>\n
 <\/p>\n
# Displays the standard heap metadata.  Replace 0xADDRESS with the heap chunk start address<\/p>\n
dt _HEAP_ENTRY 0xADDRESS<\/strong><\/p>\n
 <\/p>\n
# Displays the page heap metadata.  Replace 0xADDRESS with the start stamp address.<\/p>\n
dt _DPH_BLOCK_INFORMATION 0xADDRESS<\/strong><\/p>\n<\/blockquote>\n
One of the most important additions to the page heap header is the "user stack traces" (+ust) field.  This field contains a pointer to the stack trace of our allocated chunk.  This means that we\u2019re now able to enumerate which functions eventually lead to the allocation or free of a heap chunk in question.  This is incredibly useful when trying to track down the root cause of our exception.<\/p>\n
Both standard and full heap verification prefix each chunk with this header.  The primary difference between standard and full page heap verification is that under standard heap verification, fill patterns are placed at the end of each heap chunk (0xa0a0a0a0).  If for instance a buffer overflow were to occur and data was written beyond the boundary of the heap chunk, the fill pattern located at the end of the chunk would be overwritten and therefore, corrupted.  When our now corrupt block is accessed by the heap manager, the heap manager will detect that the fill pattern has been modified\/corrupted and cause an access violation to occur.<\/p>\n
With full page heap verification enabled, rather than appending a fill pattern, each heap chunk is placed at the end of a (small) page. This page is followed by another (small) page that has the PAGE_NOACCESS access level set. Therefore, as soon as we attempt to write past the end of the heap chunk, an access violation will be triggered directly (in comparison with having to wait for a call to the heap manager).   Of course, the use of full page heap will drastically change the heap layout, because a heap allocation will trigger the creation of a new page. In fact, the application may even run out of heap memory space if your application is performing a lot of allocations.<\/p>\n
For a full explanation of GFlags, please take a look at the MSDN documentation here<\/a>.<\/p>\n
Now the reason I\u2019ve brought this up, is that in order to replicate the exact crash generated by Peach, we\u2019ll need to enable GFlags for the GOM.exe process.  GFlags is part of the Windows Debugging Tools package which is now included in the Windows SDK.  The Windows 7 SDK, which is recommended for both Windows XP and 7 can be found here<\/a>.<\/p>\n
In order to enable full page heap verification for the GOM.exe process, we\u2019ll need to execute the following command.<\/p>\n
C:\\Program Files\\Debugging Tools for Windows (x86)>gflags \/p \/enable GOM.exe \/full<\/pre>\n
 <\/p>\n
<\/a>Initial analysis<\/h4>\n
With that said, let\u2019s begin by comparing our original seed file and mutated file using the 010 Binary Editor.<\/p>\n
Please note that in the screenshot below, \u201cAddress A\u201d and \u201cAddress B\u201d correlate with OriginalSeed.mov and MutatedSeed.mov respectively.<\/p>\n
\"RCA-Integer-Overflow-1\"<\/a><\/p>\n
Here we can see that our fuzzer applied 8 different mutations and removed 1 block element entirely (as identified by our change located at offset 0x12BE).<\/p>\n
As documented in the previous article, you should begin by reverting each change, 1 element at a time, from their mutated values to those found in the original seed file.  After each change, save the updated sample and open it up in GOM Media Player while monitoring the application using WinDbg.<\/p>\n
windbg.exe "C:\\Program Files\\GRETECH\\GomPlayer\\GOM.EXE" "C:\\Path-To\\MutatedSeed.mov"<\/pre>\n
The purpose here is to identify the minimum number of mutated bytes required to trigger our exception.  Rather than documenting each step of the process which we had already outlined in the previous article, we\u2019ll simply jump forward to the end result.  Your minimized sample file should now look like the following:<\/p>\n
\"RCA-Integer-Overflow-8\"<\/a><\/p>\n
Here we can see that a single, 4 byte change located at file offset 0x131F was responsible for triggering our crash.  In order to identify the purpose of these bytes, we must identify what atom or container they belong to.<\/p>\n
Just prior to our mutated bytes, we can see the ASCII string \u201cstsz\u201d.  This is known as a FourCC<\/a>.  The QuickTime and MPEG-4 file formats rely on these FourCC strings in order to identify various atoms or containers used within the file format.  Knowing that, we can lookup the structure of the \u201cstsz\u201d atom in the QuickTime File Format Specification found here<\/a>.<\/p>\n
Size:  0x00000100 \nType:  0x7374737A (ASCII stsz) \nVersion:  0x00 \nFlags:  0x000000 \nSample Size: 0x00000000\nNumber of Entries: 0x8000000027<\/span><\/strong>\nSample Size Table(1):  0x000094B5\nSample Size Table(2):  0x000052D4<\/pre>\n
Looking at the layout of the \u201cstsz\u201d atom, we can see that the value for the \u201cNumber of Entries\u201d element has been replaced with a significantly larger value (0x80000027 compared with the original value of 0x3B).  Now that we\u2019ve identified the minimum change required to trigger our exception, let\u2019s take a look at the faulting block (GSFU!DllUnregisterServer+0x236a9) in IDA Pro.<\/p>\n
 <\/p>\n
 <\/p>\n
<\/a>Reversing the Faulty Function<\/h3>\n
\"RCA-Integer-Overflow-3\"<\/a><\/p>\n
Without any state information, such as register values or memory locations used during run time, we can only make minor assumptions based on the instructions contained within this block.  However, armed with only this information, let\u2019s see what we can come up with.<\/p>\n