Assessing buffer-overflows with the WinDbg !exploitable extension

In this post I describe how to use the WinDbg extension !exploitable (pronounced "bang exploitable") to help assess the criticality of crashes and buffer-overflows in Windows applications.

!exploitable is a Microsoft open source project, to help improve application security by providing crash-analysis, estimating the likelihood of whether a crash could be maliciously exploited.

Buffer-overflow crashes are often found using automated fuzzing tools. When fuzzing an application, sometimes many variants of crashes can be found, especially in poorly-written or old code.

!exploitable can help show which particular crashes are most serious in terms of possible exploitation.

Here I test !exploitable on a couple of buffer overflow conditions, which are known to be exploitable, and show the results.


Why is this important?

Clearly it is important for software vendors to quickly assess crash-conditions, and address critical issues in a timely manner.

I feel that is it is also very important that a crash-assessment tool like this is accurate.

!exploitable needs to have low false-negative and false-positive rates so that software vendors can use it to accurately prioritize and triage issues (and fix the most serious first).

If there are false-positives; this could tell the software company that the crash is more serious than it really is, and bump the bug up the priority list when it may be less important than other problems.

False-negatives are possibly more serious; as if the crash is not likely to occur in normal operation, a software vendor may ignore the issue, or not get around to fixing that particular crash for some time. Meanwhile malicious 0-day exploitation of the bug may be possible, which could go undetected in the wild for a long period.


Downloading the tools

Both WinDbg and !exploitable are free and available for download.

Various versions of WinDbg are available here: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
(For these tests I chose to use the 6.11.1.404 - March 27, 2009 version as it was small and easy to install)

!exploitable is available for download here: http://msecdbg.codeplex.com/


Installation

First install WinDbg by double-clicking on the *.msi file, and following the prompts.

Register WinDbg as a “post-mortem” debugger by using

C:\Program Files\Debugging Tools for Windows (x86)\windbg -I

You can also disable the crash popups, and set auto-debugging by setting the following registry key to "0":

HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug\Auto

Installing the !exploitable extension is also a manual process.

Unpack the zip, and copy the files from "exploitable\Binaries\x86" to the target directory (C:\Program Files\Debugging Tools for Windows\winext (x86)\ by default)



Testing crashes for exploitability

WinDbg is not a pretty application, but it is very useful and extensible.

First start the WinDbg application and attach to the process you are debugging.

Then fire-off the crash conditions, get a crash, and WinDbg will show the initial crash details:


(10c4.10cc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000001 ebx=004392f8 ecx=0012ff72 edx=00000030 esi=00000037 edi=00443254
eip=0012fa96 esp=0012fa98 ebp=41414141 iopl=0 nv up ei pl nz na po cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010203
0012fa96 867ce919 xchg bh,byte ptr [ecx+ebp*8+19h] ds:0023:0a1d0993=??


You can see here that some of the CPU registers have been overwritten during this crash, for example with 41414141 ("AAAA") which was part of the payload of the proof of concept exploit.

To assess the exploitability of this crash, we can then load the !exploitable module and run the test to see if this crash is likely to be exploitable.


0:000> !load winext\msec.dll
0:000> !exploitable
*** WARNING: Unable to verify checksum for tftpd.exe
*** ERROR: Symbol file could not be found. Defaulted to export symbols for tftpd.exe -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\USER32.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\kernel32.dll -
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - Exception generated by code running in the Stack starting at Unknown Symbol @ 0x000000000012fa96 called from tftpd!_GetExceptDLLinfo+0x0000000000005eba (Hash=0x610a1635.0x584d0402)

Code execution from the stack is considered exploitable


So, that seems fair enough (I have highlighted the important parts in red).
This was a serious bug that needed to be addressed.

I know that this crash is exploitable. Exploit code is publicly available which provided unauthenticated remote code execution to an attacker.



Another example

Here is another !exploitable example. First the crash:


(1214.1428): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000043 ebx=1034f788 ecx=1034e844 edx=10360000 esi=1034e604 edi=1034e844
eip=77bd32a1 esp=1034e5a4 ebp=1034e5b0 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\msvcrt.dll -
msvcrt!wscanf+0x6c:
77bd32a1 8802 mov byte ptr [edx],al ds:0023:10360000=4d



Then the analysis:


0:017> !load winext\msec.dll
0:017> !exploitable
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files\HP OpenView\bin\ov.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files\HP OpenView\bin\ovwparser.dll -
Exploitability Classification: EXPLOITABLE
Recommended Bug Title: Exploitable - User Mode Write AV starting at msvcrt!wscanf+0x000000000000006c (Hash=0x0b367a2f.0x131d5a01)

User mode write access violations that are not near NULL are exploitable.



Again, this is pretty clear in the analysis that this was a high priority bug that needed to be fixed as soon as was practical

This was a much more complex bug to exploit, but again, unauthenticated remote code execution was possible, so a very serious issue which needed to be addressed.



My thoughts

I know that both of these crashes were exploitable, having tested both of them thoroughly in lab environments (and used them to obtain remote code execution).

My initial tests of this tool were useful. I would say that this could be a good tool for software companies, ethical hackers and penetration testers alike.

However, this was a very quick look at the !exploitable tool, and more investigation of this tool would be useful to assess the false-positive rate, and look for any false-negatives, i.e. are there any known buffer overflow exploits that this crash-analysis tool fails to identify as exploitable? and if so why?

Interestingly, it is also possible to run this tool in a batch mode for analyzing lots of crash-dumps at once. More detail in the following link:
http://msecdbg.codeplex.com/Thread/View.aspx?ThreadId=56156