HP Security Research Blog
The HP Security Research blog provides a platform for security experts from across HP to discuss innovative research, industry observations, and updates on the threat landscape to help organizations proactively identify and manage risk.

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

 

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).

 

 fig01.png

Figure 1 MS14-001 patch download section

 

 fig02.png

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.

 

 fig03.png

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.

 

 fig04.png

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.

 

 

 fig05.png

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

 

 

 

 fig06.png

Figure 6 Original code

 

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

 

 fig07.png

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)

 

 fig08.png

Figure 8 Description of CVE-2012-2593 (source: https://technet.microsoft.com/library/security/ms12-079)

 

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

 

 fig09.png

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)

 

 fig10.png

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.

 

 

 

fig11.png 

Figure 11 Exceptional case check routine (MS12-064)

 

Conclusion

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.

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Twitter: @ohjeongwook .
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.