CVE-2014-6352 OLE packager vulnerability and a failed patch for SandWorm

A few days ago, Microsoft disclosed a new vulnerability related to the Microsoft Office OLE object (CVE-2014-6352) that looks like a variant of the SandWorm vulnerability (CVE-2014-4114). While the original vulnerability was patched withMS14-060, Microsoft has released a FixIt for this new vulnerability - and we recommend you install it to protect yourself from this attack. I spent some time on this new FixIt module and wanted to share what I found.

FixIts are a useful mechanism for delivering urgent patches or simple mitigations. The mitigation delivered with this FixIt release uses Shim technology. You might not be familiar with Shim, but you can read a very good article from Microsoft on this technology. Basically, it is a mechanism to intercept API calls between Windows and the application layer. In Figure 1, you can see that the FixIt installed a Shim database for the POWERPNT.exe process.

 

Figure 1 POWERPNT.EXE Shim rule added

 

The Shim database installed here performs hot patching when the PowerPoint process starts up. Patches are applied to the loaded packager.dll image on the fly. Figure 2 shows where the CPackage::DoVerb function from the packager.dll is patched. Sound familiar? Yes, this is the exact same routine I mentioned in my last blog post about the SandWorm vulnerability. Microsoft patched a bunch of functions with MS14-060, including this one. But, a FixIt isn’t really a patch – it’s more of a workaround. Here, they just pasted 5 “int 3” instructions over the original instructions. This prevents further execution of the code and crashes the application.

 

Figure 2 Packager!Cpackage::DoVerb hot patch

 

To see exactly where the hot patch is applied, I opened up IDA and checked the position. Figure 3 shows the location of the hot patch. The call to CPackage::GetContextMenu has been removed and replaced with “int 3” instructions. This doesn’t necessarily mean that the call to CPackage::GetContextMenu itself is vulnerable, but implies that the following routines might be. This hot patch effectively disables the INF automatic installation feature.  Interestingly enough, following the instruction, there is a call to CPackage::CreateTempFile creating a temporary file from the original file before calling the INF Default Install (InfDefaultInstall.exe) program.

 

Figure 3 Packager!CPackage::DoVerb hot patch location

 

More interestingly, CPackage::CreateTempFile is one of the methods that has been patched with MS14-060. Figure 4 shows that the patched function added a call to the MarkFileUnsafe function.

 

 

 Figure 4 MS14-060 patch

 

It looks like something might not have been right with the original patch. At this point, I will wait until the real patch comes out before discussing any additional detail about this vulnerability as this is still a zero day. I’m not disclosing any critical information here, but showing you that the original fix was not perfect based on the publicly available FixIt information. However, one thing is clear - this type of attack has a high success rate if no patches or workarounds are installed, so this exploit is more dangerous. The feature disabled by this FixIt is not essential for daily business or personal use, so, I advise you to install this FixIt module as soon as possible to protect yourself from this attack.