Security Research
Showing results for 
Search instead for 
Do you mean 

Patch analysis of latest Microsoft Office vulnerability (CVE-2014-1761)

Matt_Oh ‎04-24-2014 08:00 AM - edited ‎04-24-2014 09:26 AM


I wrote about a Microsoft Word vulnerability, which was at that point a zero day, a few weeks ago. Microsoft released the update for this vulnerability with their April 2014 Patch Tuesday. There is some confusion in the industry about the nature of this vulnerability, so I analyzed the patch -- in the process, confirming my previous findings. This blog discusses my results, along with some additional interesting findings related to previous security updates of the RTF parser in Microsoft Office.


Analyzing MS14-017

CVE-2014-1761 was patched with security bulletin MS14-017. MS14-001 was the latest relevant security update before this update. I compared WWLIB.DLL binaries extracted from MS14-001 (pre-patch binary) and MS14-017 (post-patch binary).



Figure 1 MS14-001 patch download section



Figure 2 MS14-017 patch download section


The target binaries are bigger than other Windows DLLs, which is common for Office binaries. It takes some time to get the patch analysis results, when running patch analysis tools. I used the DarunGrim tool to perform this analysis. Figure 3 shows the result of this tool. The selected line represents the patch for CVE-2014-1761. The unpatched and the patched functions have 99% similarity.



Figure 3 Patched functions list (CVE-2014-1761 update highlighted)


Figure 4 shows the bird’s-eye view of this function. Both functions look similar in a bird’s-eye view; this figure shows one from the unpatched binary.



Figure 4 Patched function bird's-eye view


When I looked into the actual patched basic blocks (Figure 5), I noticed that one block (yellow) is modified and two new blocks (red) are added. The code at address 0x31D14348 (cmp eax, edx) is the line where the sanity check happens. The vulnerability is an out-of-bounds memory write; edx from this line represents the total size of the memory array and eax represents current index from that array. This code is inside a loop and as the loop goes on, the index value will increase. With the previous code (Figure 6) the bounds check doesn’t happen, which leads to memory corruption.




Figure 5 Added code (red), modified code (yellow)





Figure 6 Original code


Figure 7 shows the code where the out-of-bounds memory write happens.



Figure 7 Vulnerable code



Analyzing MS12-079

During my analysis, something interesting caught my eye. From Microsoft’s security bulletin MS12-079 update, the description mentions the same RTF control word (listoverridecount) that is also related to CVE-2014-1761. (Figure 8)



Figure 8 Description of CVE-2012-2593 (source:


There was already a blog post regarding the similarity of the two vulnerabilities as well as discussions on Twitter. (Figure 9)



Figure 9 Conversation on Twitter


I put some effort into finding what issues were patched with the MS12-079 update. From my analysis the vulnerability patched with the bulletin is very similar, but not the same. There are a lot of updates in the code with MS12-079, but the only location I could find that is related to listoverridecount RTF control word is in the same function as the location where the MS14-019 patch for CVE-2014-1761 exists. (Figure 10)



Figure 10 Patched locations in the same function



Figure 11 shows the code where the update exists. The routine here actually checks whether listoverridecount control word is used with an argument of 0. The line at 0x31D117FF (and dword ptr [esi+8], 0) nullifies the memory area pointed to by esi+8 when an argument of 0 is passed with listoverridecount control word. This doesn’t happen with the original code and I found that there is a  slight chance of using uninitialized memory in that case.





Figure 11 Exceptional case check routine (MS12-064)



By using patch analysis techniques, even without source code, one can analyze security updates. I also found that MS12-079 and MS14-017 are closely related to each other. The actual code location is very close; the fact that an exceptional argument for same RTF control word triggers the vulnerability is the same. It is also interesting that we see similar bugs happening around the same code area or component over and over again. While I cannot say as to why this is occurring, I believe this might be a very interesting topic to research to determine if this is due to human factors or not.


0 Kudos
About the Author


Twitter: @ohjeongwook .

27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all