#Mem patch 2017 code
#Mem patch 2017 series
#Mem patch 2017 free

At the patch location in original code a jmp instruction is written (consuming 5 bytes of original instruction space) that redirects execution to a memory block designated for patch instructions. The way patching works is that a jump is made from original to patch code and then back. However, selecting the exact patch location is not just about where to logically fit the modifications that we want to apply.

#Mem patch 2017 series

An appropriate spot seems to be right before the first series of checks that validate the EMRSETDIBITSTODEVICE attributes (see cmp - jg pairs in the above code screenshot that end with a jmp to function exit in case any of the checks fail).

What principally needs to be done is adding a check whether cbBitsSrc is smaller than cxSrc * cySrc * 4 before any image pixels get copied around. So to fix the flaw a check has to be added before any data gets stolen. When processing the PoC EMF file, the EMRSETDIBITSTODEVICE structure (detailed in the lower right pane of the screenshot above) passed to the MRSETDIBITSTODEVICE::Play function as the first argument ( rcx register that gets stored to rbx, marked in blue) contains cbBitsSrc set to 4, which does not match the 0x10 * 0x10 image dimensions defined by cxSrc and cySrc (these amount to 256 pixels or 1024 bytes). Height of the source rectangle, in logical units.ДЄfter feeding WinDbg with symbols for EMRSETDIBITSTODEVICE type (explanation follows later) the explanation from the report finally got clear. Width of the source rectangle, in logical units. It says cbBitsSrc is not checked against 'the expected number of bitmap bytes' - the number which is calculated from cxSrc and cySrc image dimensions. With that piece of info in hand we can attach WinDbg to iexplore.exe and set a breakpointДЄccording to the report this is where all the trouble is. This is important because the PoC produces no crash or exception that could be caught by a debugger for an in-depth analysis. Luckily the next thing that the report conveniently reveals is the name of the vulnerable function MRSETDIBITSTODEVICE::bPlay. Before we do that we need to understand where the vulnerable code is. So the only pixel that originates from the actual data provided by the EMF file is that one (represented by the 4 bytes) - everything else is heap data read from out of bounds of the image pixel data. This is consistent with the report (one only needs to look closely enough). Diffing the results after consecutive PoC reloads showed that the only pixel that didn't change was the one in the lower left corner (if you look really closely at the screenshot above you will find a red smudge right there). In order to see the pixel values I put poc.emf onto an HTML canvas and printed the pixel values with JavaScript. And it did leak consistently: reloading the PoC resulted in a different image on each reload. The image had to be zoomed in to the max in order to see the intimidating heap data leaking through the colorful pixels.

Mateusz's PoC worked as advertised - by launching an instance of IE 11 and dropping poc.emf onto it, this is the result I got: I have to kindly thank Mateusz Jurczyk of Google Project Zero for a terse and accurate report that allowed me to quickly grasp what the bug was about and jump on to 0patching it. An attacker could use this vulnerability to steal sensitive data that an application holds in memory or as an aid in other exploits when ASLR needs to be defeated. If image dimensions are large enough the parser is tricked into reading memory contents beyond the memory-mapped EMF file being parsed.

#Mem patch 2017 free

I had some free time last week to look into the matter and as a result I can give you the very first 0patch for a 0-day.Д¬VE-2017-0038 is a bug in EMF image format parsing logic that does not adequately check image dimensions specified in the image file being parsed against the amount of pixels provided by that file. But don't worry, every cloud has a silver lining. Consequently a number of 0-days are getting published, with CVE-2017-0038 being the first one on the list. Then along came Mitja and asked:ДЄs you've probably noticed, the last Patch Tuesday didn't make it. I've been fishing around the web for my next target to patch when something got caught into my net. My first 0-day fixed (and I am not even a Microsoft developer)