As time progresses, due to constant fuzzing and auditing many common Microsoft products are becoming reasonably hard targets to fuzz and find interesting crashes. There are two solutions to this: write a better fuzzer (http://lcamtuf.coredump.cx/afl/) or pick a less audited target.
In a search for less audited attack surface, we are brought to MS14-038, Vulnerability in Windows Journal Could Allow Remote Code Execution (2975689). Before we start attacking this application, we would like to understand the vulnerability addressed by MS14-038.
Windows Journal is a tablet component shipped with Windows Vista forward, meant for taking notes and such. It has a file association of ‘.jnt’.
The bulletin doesn’t give too much information, but reveals the problem is some kind of parsing issue. The patch seems to address issues in NBDoc.dll, so let’s look at the bindiff of pre/post patch.
The diff is ugly, many functions have changed and a few have been added/removed. So where do we go from here? Looking at the individual changes, we come across a few fixes that look security related, but after numerous dead-ends, one is more attractive than the rest – sub_2ECE0B90. A high level view of this function is seen below.
This function is somewhat big and has quite a few changes, but is interesting for a couple reasons:
First off, apart from some structural changes, there are several calls to memcpy in the unpatched function. Only one of these has been converted to a memcpy_s in the patched function, the count of which is now passed in as an argument to the function.
Secondly, the function looks like it contains some kind of magic value at the top. In the very first basic block, further processing is determined by a call to strncmp, searching for the string “PTC+MSHM”. Perhaps this could be a useful marker for which to search.
Assuming that this string is in fact a marker for a path to the vulnerable function we perform a quick Google search.
After digging around on archive-ro.com, we end up with a link to a journal file:
Popping this guy open in a hex editor, we get dozens of hits for PTC+MSHM on a free text search
We now proceed dynamically, attempting to trigger a breakpoint in the affected function. We set one in the first block of the function of the unpatched DLL near the call to strncmp on “PTC+MSHM”. Upon hitting it the first time it, the str1 argument looks like this:
Grabbing all the bytes up till the second occurrence of 0f61 and flipping the endian, we get two hits in our hex editor, one at offset 0x04df and one at offset 0x2bcb.
The second hit is different from the dump, lacking the next word 0b70. So it looks like we are handling this blob at offset 0x04df in the file during the first function call.
Continuing on, we set a breakpoint above the memcpy of interest at the top of the block. After some stepping we get to this situation:
Well, that 0x0b70 looks familiar… Furtermore, it appears to be pushed as the size parameter to the memcpy. Let's modify the initial file, changing 700B to FFFF.
Restarting the application and opening our modified file, we receive an access violation.
So as hoped, we crash in the memcpy and have exercised the vulnerable code. More than this particular vulnerability we are trying to isolate, this crash seems like it may be more indicative of less audited code then, say, MS Word.
With visions of unbounded memcpy’s in our eyes, we fired a dumb fuzzer at the current version of Journal – and as expected it fell over pretty quickly and in several unique ways -- we encourage you to do the same.
The diff is ugly, many functions have changed and a few have been added/removed. So where do we go from here? Looking at the individual changes, we come across a few fixes that look security related, but after numerous dead-ends, one is more attractive than the rest – sub_2ECE0B90. A high level view of this function is seen below.
This function is somewhat big and has quite a few changes, but is interesting for a couple reasons:
First off, apart from some structural changes, there are several calls to memcpy in the unpatched function. Only one of these has been converted to a memcpy_s in the patched function, the count of which is now passed in as an argument to the function.
Secondly, the function looks like it contains some kind of magic value at the top. In the very first basic block, further processing is determined by a call to strncmp, searching for the string “PTC+MSHM”. Perhaps this could be a useful marker for which to search.
Assuming that this string is in fact a marker for a path to the vulnerable function we perform a quick Google search.
After digging around on archive-ro.com, we end up with a link to a journal file:
Popping this guy open in a hex editor, we get dozens of hits for PTC+MSHM on a free text search
We now proceed dynamically, attempting to trigger a breakpoint in the affected function. We set one in the first block of the function of the unpatched DLL near the call to strncmp on “PTC+MSHM”. Upon hitting it the first time it, the str1 argument looks like this:
Grabbing all the bytes up till the second occurrence of 0f61 and flipping the endian, we get two hits in our hex editor, one at offset 0x04df and one at offset 0x2bcb.
The second hit is different from the dump, lacking the next word 0b70. So it looks like we are handling this blob at offset 0x04df in the file during the first function call.
Continuing on, we set a breakpoint above the memcpy of interest at the top of the block. After some stepping we get to this situation:
Well, that 0x0b70 looks familiar… Furtermore, it appears to be pushed as the size parameter to the memcpy. Let's modify the initial file, changing 700B to FFFF.
Restarting the application and opening our modified file, we receive an access violation.
So as hoped, we crash in the memcpy and have exercised the vulnerable code. More than this particular vulnerability we are trying to isolate, this crash seems like it may be more indicative of less audited code then, say, MS Word.
With visions of unbounded memcpy’s in our eyes, we fired a dumb fuzzer at the current version of Journal – and as expected it fell over pretty quickly and in several unique ways -- we encourage you to do the same.
