This is most likely because exploit code for Microsoft Office is much harder to develop. Indeed, for IE, the “control vector” has been standardized over time: code for heap spraying can be reused, and in effect, numerous exploit developers just copy and paste Heap Spraying code from previously available exploits. And once the Heap Spraying is done, a jump to supposedly invalid memory triggered by bogus input fed to the browser has a high chance of landing in the shellcode (actually, in a NOP slide leading right to it).

But for Microsoft Office, say for instance in the context of an Excel vulnerability, the shellcode must sit in the file record and the exploit developer has to find a way to transfer the execution flow to its precise location in the memory, rather than just forcing a random jump. Now, if we can spray the heap in Microsoft Office, the shellcode will virtually reside “everywhere” in memory. Thus turning a possible flaw into a reliably exploitable vulnerability becomes considerably easier. So… how can we spray the heap in MS Office?

In July 2009, Julia Wolf at FireEye Malware Intelligence Lab found an exploit that uses ActionScript to spray the heap in Adobe Flash. So, theoretically, if we embed such a flash in an Office document, we should be able to spray the heap just as good, shouldn’t we? In any case, it is certainly worth a try…

Following is my experimental environment:

• OS: Windows XP SP3
  
• Microsoft Office: 2003 professional
  
• Flash player: 10.0.32.18
  

First, we need to create a heap-spraying flash. That is easy now with ActionScript (see here and there).

Then, we need to embed this flash into an Office document. Excel probably being the most vulnerable MS Office application, let’s resort to an Excel document for the sake of the experiment.

Finally, we set the security (Tools->Macro) to “very high” in Excel 2003 and open the Excel document… As can be seen on the figure below, the document opens fine without even a warning box.

Let’s check the process memory with Ollydbg. As can be seen in the following figure, multiple Virtual Address Buffers of size 0×10001000 containing our NOP slides + shellcode cocktails were effectively allocated all over the heap.

This means that no matter how high the security is set to, exploits developers can now spray the heap of Microsoft Office.

It can be noted that if there are both Macros and flash in the Excel document, exploit reliability diminishes; indeed, the ActionScript code will be disabled along with Macros (if the user has chosen to disable Macros, of course).

We’ve also tried to open this document with Excel 2007 under Windows Vista. The heap spraying still works.

To put it in a nutshell, with ActionScript in flash, attackers have all the tools in their hands to develop workable exploits for Microsoft Office vulnerabilies. It may therefore be a good time to review your defense policies regarding Office documents… Are they scanned for malware on your Mail server? Are your end-users who’ll open them super-users of their desktop machines? Is your Gateway configured to block outbound access to the malware pieces (trojans, keyloggers, password stealers, sniffers) meant to be fetched upon embedded shellcode execution? When your users bring their work laptop home, are they still protected there?

Note: In accordance to our responsible disclosure policies, Microsoft was officially notified. No fix will ensue.

Guillaume Lovet contributed to this report