When The Pwnie Awards, aka the Oscars of security research, unveiled this year’s nominees on July 22, 2010, we were excited to discover that Fortinet researchers Guillaume Lovet and Haifei Li were nominated in the category of “Most Innovative Research” for their  paper “Adobe Reader’s Custom Memory Management: A Heap of Trouble.”

“Most Innovative Research” is awarded to the person(s) who published “the most interesting and innovative research in the form of a paper, presentation, tool or even a mailing list post”.

Guillaume and Haifei’s research paper dug deeply into the custom heap management of Adobe’s PDF Reader. They found that when Adobe Reader is processing a PDF file, in most allocation cases, it does not directly use the system’s heap, but maintains its own heap management system on top of the system-level heap management system. This feature provides an easier and reliable way to leverage PDF heap-based vulnerabilities.

The paper dissects the reader’s mechanisms and points out weaknesses by showing how an attacker can obtain exact EIP control in many different heap corruption situations.

On March 31, 2010, Guillaume and Haifei posted a video podcast that explained the vulnerability in detail and showed a working exploit for a PDF zero-day vulnerability. And on April 23, 2010, the two posted their Black Hat Europe 2010 presentation, as well as a whitepaper and source code, all of which can be found here.

The Pwnie Awards is an annual award ceremony that celebrates the achievements and failures of security researchers and the security community. The awards are given out once an year, and the fourth annual ceremony will take place on July 28th, 2010 in Las Vegas at the BlackHat USA security conference. This year’s esteemed judges include Dave Goldsmith, Mark Dowd, Dino Dai Zovi, HD Moore, Dave Aitel, Halvar Flake and Alexander Sotirov.

Other nominees in the category of “Most Interesting Research” include Dionysus Blazakis for his report “Flash Pointer Inference and JIT Spraying,” Joshua Mason, Sam Small, Fabian Monrose and Greg MacManus for their report “English Shellcode,” John McDonald and Chris Vasalek for their report “Practical Windows XP/2003 Heap Exploitation,” Julien Vanegue for the report “Zero-sized heap allocations vulnerability analysis” and Juliano Rizzo and Thai Duong for their report “Practical Padding Oracle Attacks.”

A complete list of award categories and nominations can be found here.

Heap Spraying is a technique that can effectively increase the reliability of flaw exploitation code (aka “exploits”) on various OS, and in many cases, go as far as enabling an exploit that would practically not “work” otherwise. It contributed tremendously to the popularity of exploits targeting Web browsers over the last years. As a matter of fact, it ended bothering Microsoft to the extent a protection against Heap Spraying was introduced in IE8.

Besides Internet Explorer, Microsoft Office is also a privileged target of vulnerabilities researchers, and as such, present a myriad of public flaws – especially concerning the compound file format document. Yet, it seems that exploits targeting MS Office are not anywhere as popular or common as those aiming at IE.

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