Blog

Triggering MS16-030 via targeted fuzzing

Posted by Bill Finlayson on Oct 11, 2016 11:05:35 AM

Find me on:

The need to analyze the patch for MS16-030 recently presented itself to us due to some related product research.  After the analysis was complete, we realized that the attack surface of the patch was pretty interesting and determined it may be beneficial to share part of the analysis.  This post will focus on triggering a patched bug from MS16-030.

An abbreviated list of the changes made to OLEAUT32 are visible below.

changed.png

In looking at the list of changed functions, we chose to peruse OLEAUT32!_ResToIcon here, but imagine the process may apply to other changes.  Lets take a look at the graph overview of the modifications to ResToIcon, which we can assume performs some function related to icons.

diff_overview.png

There are a ton of changes here, but we need to determine if they are in fact security fixes.  Let’s zoom in to some blocks.

resiconchanges_good.png

Yeah, this looks good for our purposes.  There are two calls we can see here: SizeTAdd and ULongLongToULong.  Checking the documentation:

SizeTAdd - This is one of a set of inline functions designed to provide arithmetic operations and perform validity checks with minimal impact on performance.

ULongLongToULong  - This is one of a set of inline functions designed to provide type conversions and perform validity checks with minimal impact on performance.

Nice, this seems like relevant code.  Now how can we exercise this code path?  We need to find a path from an entry point  in OLEAUT32 to the fixed function OLEAUT32!_ResToIcon.

path_to_restoicon_in_oleaut.png

 As we can see above there are several candidates, but after some consideration (and trial and error) we decided to go with OLEAUT32!_OleLoadPicture which is imported by vbscript.dll.

Opening vbscript.dll in IDA, we map paths from OleLoadPicture and they are thankfully very simple.

path_to_load_pic_in_vbscript.png

It seems as though we just need to call vbscript!VbsLoadPicture which is accessible via the vbscript LoadPicture API. Being lazy, we attempted the naive approach and set a breakpoint at the call to OleLoadPicture in vbscript!VbsLoadPicture and opened an icon with the affected API. This did not work..  We bounced off some kind of check.

stgfile.png

The problem is that in the logical path to OLEAUT32!OleLoadPicture is  blocked off for us by a call to ole32!StgIsStorageFile.  What is this API?

"The StgIsStorageFile function indicates whether a particular disk file contains a storage object."

Looking at MSDN, we get the very minimal information above.  Further Googling leads us to the fact that we are dealing with a notion of COM Structured Storage, and this nice blurb below (again from MSDN).

'''Structured Storage provides file and data persistence in COM by handling a single file as a structured collection of objects known as storages and streams.'''

So it appears as though we need to create a Structured Storage object and insert an icon in it to reach the desired OLEAUT32!OleLoadPicture call.  How can we create this file?

Some further googling leads us to an (awesome) tool to accomplish this called  OpenMCDF ( http://openmcdf.sourceforge.net).  So all we have to do is make a stream off the structured storage root that contains an icon and open the resulting file again with a vbscript call to LoadPicture.  So we made one with the Structured Storage eXplorer included in OpenMCDF.

create_icon_one.png

After this, we set our breakpoint at at OleLoadPicture and open this new file.  The breakpoint wasn’t hit...   What’s going on??  

After some analysis, it seems that we are bouncing off another check.

Contents.png

Our current path follows the pink blocks, our desired block is in green.  The logic appears to be validating  the name of the stream against the string "CONTENTS".  Let's rename our stream from “icon” to “CONTENTS” and try again.

create_icon_two.png

This file caused a hit at our breakpoint in OleLoadPicture.

Now, from the same windbg session we then set another breakpoint in OLEAUT32!_ResToIcon to determine if the fixed function was hit by this file.

breakpoint.png

So, we did indeed hit our breakpoint. 

From here we know that our input is reasonably close to the changed code, lets just fire a fuzzer at it and monitor it for faults.  Here we are using a dumb fuzzer to generate mutated candidate files, a hacked vbscript harness to open the files, and eEye faultmon to perform automated debugging. Additionally, we were sure to enable gflags page heap.  The ugly fuzzer harness can be seen below.

fuzzer.png

We don’t have to wait very long here as faultmon gives us a crash on the 612th iteration.  Let’s open it in windbg...

crash.png

Nice, we triggered (one of the) patched bugs.  We then verified the work by ensuring the crash did not occur after the patch was installed.

Analyzing patches is fun, but really the takeaway here for us was bindiffing sometimes allows us to understand new or less traveled attack surface.  This concept of packing up file types into structure storage to hit different parsing code is pretty interesting and may be fruitful in future fuzzing efforts.

 

Topics: fuzzing, patch analysis, Microsoft, Threat Labs, reverse engineering

Subscribe to the Vectra Blog



Recent Posts

Posts by Topic

Follow us