!exploitable Crash Analyzer - MSEC Debugger Extensions

Updated Release: !exploitable 1.6 (May 01, 2013)

AndyRenk — Thu, 02 May 2013 00:17:27 GMT

1.6.0 Updates:

ARM Dump Support Added
Changed default hashing algorithm to SHA256
Added Support to chose the hashing algorithm used (for backwards compatibility)
Added support for custom exclude hash list
Updated -v output to show which frames are used to determine the major and minor hash
Added version number logging
Added line number and source file reporting
Added checking for exception handler chain corruption as an Exploitable case
Added Stack Exhaustion as a Probably Not Exploitable case
Added more AppVerifier symbols to the excluded symbols list
Added checking for kernel mode code running in user land as an Exploitable case
Moved "Read AV Near Null" to terminal rule status
Added "App Verifier Stop Detected"
Moved "Read AV Near Null" to Probably Not Exploitable
Moved "Write AV Near Null" to Unknown
Added the XLAT command for x86 and x64
Correctly pull the TEB32 for WOW process on 64 bit Windows
Translate stack exhaustion cases that manifest as Write AVs into stack exhaustion
Changed the naming of Stack Overflow to Stack Exhaustion
Fixed a bug in the logic determining if code is in user or kernel space

Released: !exploitable 1.6 (May 01, 2013)

Thu, 02 May 2013 00:17:27 GMT

Updated Wiki: Home

AndyRenk — Thu, 02 May 2013 00:17:09 GMT

Project Description
!exploitable (pronounced “bang exploitable”) is a Windows debugging extension (Windbg) that provides automated crash analysis and security risk assessment. The tool first creates hashes to determine the uniqueness of a crash and then assigns an exploitability rating to the crash: Exploitable, Probably Exploitable, Probably Not Exploitable, or Unknown. There is more detailed information about the tool in the following .pptx file or at http://www.microsoft.com/security/msec. Additonally, see the blog post at http://blogs.technet.com/srd/archive/2009/04/08/the-history-of-the-exploitable-crash-analyzer.aspx, or watch the video at http://channel9.msdn.com/posts/PDCNews/Bang-Exploitable-Security-Analyzer/.

This tool was created by the Microsoft Security Engineering Center (MSEC) Security Science Team. For more information on MSEC and the Security Science team, please visit http://www.microsoft.com/security/msec. To see what's being worked on presently, visit the Security Research and Development blog at http://blogs.technet.com/srd/.

New bits posted on 5/1/2013, changelog below:

1.6.0 Updates:

ARM Dump Support Added
Changed default hashing algorithm to SHA256
Added Support to chose the hashing algorithm used (for backwards compatibility)
Added support for custom exclude hash list
Updated -v output to show which frames are used to determine the major and minor hash
Added version number logging
Added line number and source file reporting
Added checking for exception handler chain corruption as an Exploitable case
Added Stack Exhaustion as a Probably Not Exploitable case
Added more AppVerifier symbols to the excluded symbols list
Added checking for kernel mode code running in user land as an Exploitable case
Moved "Read AV Near Null" to terminal rule status
Added "App Verifier Stop Detected"
Moved "Read AV Near Null" to Probably Not Exploitable
Moved "Write AV Near Null" to Unknown
Added the XLAT command for x86 and x64
Correctly pull the TEB32 for WOW process on 64 bit Windows
Translate stack exhaustion cases that manifest as Write AVs into stack exhaustion
Changed the naming of Stack Overflow to Stack Exhaustion
Fixed a bug in the logic determining if code is in user or kernel space

1.0.6 Updates:

External Release: June, 2009

1.0.5 Updates:

Updates to the excluded symbols list
Handle POP instructions that pop to memory
Handle PUSH instructions that push to memory
Treat POP instructions to memory the same as MOV instructions to memory

1.0.4 Updates:

Fixed a reporting and analysis bug, in which we change the faulting instruction as well as the invoking function when we skip excluded stack frames

1.0.3 Updates:

New state and gather functionality and analyze rules to identify exceptions where the faulting address is on the stack.
Hashes are fixed at 32 bit display (8 hex characters) and code locations are fixed at 64 bit display (16 hex characters).
Added support for the REP SCAS instruction in the disassembler
Fixed a serious bug in the wildcard match function, which would result in anything that matched up to the first wildcard matching the entire string
Fixed a bug in which the destination pointer registers were not being set to the tainted value set for Write AVs that required taint analysis
Fixed bugs in the distinction between source and data registers for taint tracking in some rep instructions

1.0.2 Updates:

When loading user mode mini-dumps, the Gather rule now correctly sets the stack context.

1.0.1 Updates:

A bug that resulted in overtainting H or L registers has been fixed.
Initial External Release: March, 2009

Updated Release: !exploitable 1.6 (May 01, 2013)

AndyRenk — Thu, 02 May 2013 00:11:40 GMT

Updated Release: Automation Scripts (May 01, 2013)

AndyRenk — Thu, 02 May 2013 00:11:06 GMT

Classify - A batch file used to sport crash dumps based on !exploitable output.
DebugWrapper - A batch file used to debug an application. If a crash occurs it is evaluated by !exploitable and a crash dump is saved and sorted.

Released: Automation Scripts (May 01, 2013)

Thu, 02 May 2013 00:11:06 GMT

Source code checked in, #83548

AndyRenk — Wed, 01 May 2013 21:45:35 GMT

1.6 update to !exploitable

Updated Release: MSEC Debugger Extensions v1.0.6 (Jun 17, 2009)

AndyRenk — Thu, 13 Dec 2012 02:41:16 GMT

New MSECExtensions bits, changelog below:

1.0.1 Updates:

A bug that resulted in overtainting H or L registers has been fixed.
Initial External Release: March, 2009

1.0.2 Updates:

When loading user mode mini-dumps, the Gather rule now correctly sets the stack context.

1.0.3 Updates:

New state and gather functionality and analyze rules to identify exceptions where the faulting address is on the stack.
Hashes are fixed at 32 bit display (8 hex characters) and code locations are fixed at 64 bit display (16 hex characters).
Added support for the REP SCAS instruction in the disassembler
Fixed a serious bug in the wildcard match function, which would result in anything that matched up to the first wildcard matching the entire string
Fixed a bug in which the destination pointer registers were not being set to the tainted value set for Write AVs that required taint analysis
Fixed bugs in the distinction between source and data registers for taint tracking in some rep instructions

1.0.4 Updates:

Fixed a reporting and analysis bug, in which we change the faulting instruction as well as the invoking function when we skip excluded stack frames

1.0.5 Updates:

Updates to the excluded symbols list
Handle POP instructions that pop to memory
Handle PUSH instructions that push to memory
Treat POP instructions to memory the same as MOV instructions to memory

1.0.6 Updates:

External Release: June, 2009

Released: MSEC Debugger Extensions v1.0.6 (Jun 17, 2009)

Thu, 13 Dec 2012 02:41:16 GMT

Source code checked in, #79962

Project Collection Service Accounts — Mon, 01 Oct 2012 21:14:48 GMT

Upgrade: New Version of LabDefaultTemplate.xaml. To upgrade your build definitions, please visit the following link: http://go.microsoft.com/fwlink/?LinkId=254563

Source code checked in, #79961

Project Collection Service Accounts — Mon, 01 Oct 2012 21:08:39 GMT

Checked in by server upgrade

Source code checked in, #76360

AndyRenk — Tue, 15 May 2012 17:19:05 GMT

Bind source Control

Source code checked in, #76359

AndyRenk — Tue, 15 May 2012 17:09:46 GMT

Initial checking of !exploitable to TFS

New Post: Major/Minor hash

AndyRenk — Thu, 03 May 2012 16:49:11 GMT

The hashes are 32 bit numbers and it is encoded in hex, 32 memory addresses share the same property.

The Major hash is calculated over the first five frames of a stand and does not include the offset from a symbol. This allows for stacks to have small variances to end up with the same hash. The Minor hash is calculated over the top 64 frames and includes offsets. So if you have two crashes with the same minor hash you know they have crashed at the exact same spot and most likely are the same issue.

New Post: Can't build 64bit msec.dll under .NET 4

AndyRenk — Thu, 03 May 2012 16:44:39 GMT

Binaries are shiped with the source code, there is a x64 verion in there.

New Post: Some documentation on the tool

AndyRenk — Thu, 03 May 2012 16:43:43 GMT

Slides from the presentation given at CanSecWest 2009

http://download.microsoft.com/download/7/2/8/728FE40F-93B6-47BD-B67D-78D04B63E27D/Automated%20Security%20Crash%20Dump%20Analysis.pptx

New Post: Arguments to debugWrapper script

AndyRenk — Thu, 03 May 2012 16:32:00 GMT

I hope the following example helps clarify the issue.

debuggerWrapper.cmd takes 5 arguments

The program to debug
The command line to the program
The path to the file being tested
- This is needed because not all programs consume a file from the command line. Without this argument it would not be possible to copy the file to the repro location when a crash occurred.
Max Time in seconds to debug the program
The directory to save crashes and repro files too.

In this example lets say you want to test the string literal search functionality of findstr.exe. The command line to this this is "findstr.exe /C:string filename". You have created a file named:\Files\TemplateFile.txt that you want to use as the file. If the debuggerWrapper detects a problem you want the files saved to c:\repro. To Run this scenario you would use the following command line.

DebuggerWrapper.cmd %systemdir%\system32\findstr.exe "/C:string C:\Files\TemplateFile.txt" C:\File\TempalteFile.txt 5 C:\repro

New Post: Arguments to debugWrapper script

heykart — Mon, 21 Nov 2011 22:07:02 GMT

Hi, I think the debugWrapper script is going to be useful to me. Would anyone be able to explain these two parameters to the script?

@REM ^%~2 = command line arguments including tempate name if needed. I.E. "/C:search" TemplateFile.txt
@REM ^%~3 = Temple file to process.

What is a template file supposed to be, and which parameter number should it be? Which parameter number should the input file, that causes an application crash, be? I'm a bit confusion by the repetition of "template" in parameters 2 and 3.

Thanks for the help!

New Post: Some documentation on the tool

tosanjay — Tue, 21 Dec 2010 15:46:25 GMT

Hi,

In the introduction to the tool, it is mentioned that more details are provided in the following .pptx file, but I could not get any file. I am looking for details on how this tools classifies the vulnerability as highly/less exploitable i.e. what are the parameters that are considered. Pointer to any articles or blog entries are appreciated.

thanks & regards

-sanjay

New Post: Can't build 64bit msec.dll under .NET 4

puckaby — Wed, 17 Nov 2010 07:53:53 GMT

I get this error when trying to load MSECDbgExts64 in Visual C++ 2008 express :

The project consists entirely of configurations that require support for platforms which are not installed on this machine.

I think it has something to do with the latest version of the windbg SDK for win 7 and .NET framework 4. Any thoughts? Has anyone tried this and have it work?

I was able to build MSECDbgExts32 but that dll isn't compatible with the 64bit version of the debugger I installed on my OS (win 7 home premium).

Thanks!

EDIT: Never mind, I saw the readme caveat that that express edition of C++ won't work for the 64bit.