The recent PDF Javascript zero-day (CVE-2009-4324) vulnerability has been making quite some noise lately – both in the media and in the wild. The nature of the vulnerability exploited by the samples in the wild is now clearer: It is a use-after-free vulnerability. Here is a peek at the vulnerable code, to provide a base for future research and mitigation.

The incriminated code handling the “doc.media” object is in the file “plugins\Multimedia.api”; here, when function “newPlayer()” is being called, a block of 0×4C bytes is allocated on the heap, at the first address highlighted in red on figure 1 below:

Figure 1: call to malloc()

Then it goes to free this 0×4C bytes long block – as can be seen on figure 2 below – because of the unexpected input fed by the malicious Javascript code.

Figure 2: free()

However, when the Javascript interpretation ends (normally, or because of any other actions bringing the same effect, such as “util.printd()” in the sample), the memory of this freed block is used again:

Figure 3: Use after free!

As we can see on figure 3, the first pointer in the previously-freed block is stored in edx for the purpose of being used as a vtable pointer (aka vpointer). Then, the function at index 0×04 in the vtable is called (highlighted address on Figure 3). In other words, the EIP is set to [[lpBlock] + 4].

Therefore, successful exploitation lays in the attacker’s ability to control the first DWORD value in the block, so as to have it point to his/her own crafted “vtable”, and branch to his/her own “vfunction” (the shellcode). The easiest way we can think of to achieve this is to insert some PDF Javascripts; this hopefully will reallocate memory at the same spot as the freed block, because the Javascript engine uses the same heap. This is the approach implemented in the sample seen in the wild.

As the vendor’s patch is currently planned to be available on January 12, 2010 after Christmas and New Year, Fortinet customers should ensure that your IPS and AV definitions are up-to-date, we released updates to detect the exploits on Dec 15th, 2009 (more details can be found in our FortiGuard Advisory FGA-2009-47).

Guillaume Lovet contributed to this post

Over the last year, a growing number of PDF vulnerabilities have been seen in the wild, and no matter whether these vulnerabilities were disclosed as zero-day attacks, or followed the responsible disclosure process; it indicates that more and more attention is being given to PDF vulnerabilities by underground vulnerability discoverers, attackers, and security researchers like us. Right now the Adobe Reader has become a PDF-based platform which supports a variety of scripts (not only JavaScript), rich medias (such as movie, Flash), and even text-based describing languages (such as XML). Here I would like to take this opportunity to talk a little about the history as well as the effort of our research on these areas.

1. JavaScript in PDF.

This was the prolific area of PDF vulnerabilities and our research on it was launched as early as the latter half of 2007. The PDF JavaScript functions can be divided into two classes: The documented functions and the undocumented functions. The documented functions can be found at Adobe’s JavaScript for Acrobat API Reference, and usually, you can rather easily write a JavaScript based fuzzer to test these APIs. However, there are more security problems with the undocumented APIs. To audit these APIs, we worked hard to gain the prototype of these functions by reverse engineering. Here is an interesting example we reported in November 2007, which is also mentioned as a case study in this nice paper from ImmunitySec Inc.

2. Binary stream handling vulnerabilities.

After the disclosing of dozens of PDF JavaScript API vulnerabilities during the year 2008, the binary stream handling vulnerabilities has become the main trend in 2009. Considering that the most common mitigation method for JavaScript vulnerabilities does not work on this kind of vulnerabilities, and sometimes even performing a single-click on the PDF file through Windows’ file explorer will trigger the vulnerability in “AcroRd32Info.exe” (it often happens in handling font streams). Overall binary stream handling vulnerabilities are more threatening than others.

As a typical example, you may remember the JBIG2 vulnerability, which was disclosed as a zero-day attack in February this year. We also discovered one which is a fault in handling TrueType font stream.

Almost always the stream is encoded by some filters (as we know, the most common filter is “FlateDecode”), thus it is important to decode it firstly if you want to look further (such as analysis or fuzzing), we also developed some tools to extract and decode streams in PDF automatically:

3. Multimedia/new feature introduces vulnerabilities.

The latest PDF zero-day attack highlights the multimedia side of Adobe Reader, as well as some other new features. We now know that it is actually a SWF vulnerability which affects both Flash Player and Adobe Reader 9. Looking a little bit deeper on it you will find that it is a new feature which was introduced in Adobe Reader 9, see the following test:

Do you still think Adobe Reader is only a “Reader”? Of course, we are not calling out Adobe Reader as inherently insecure. But as every piece of software in this World, as its complexity grandly increases, so does the probability of flaws being discovered.

The Fortinet’s FortiGuard Global Security Research Team is working actively on these areas and monitoring closely any possible PDF related threats in the wild. And, we will continue reporting PDF vulnerabilities to the Adobe Product Security Incident Response Team, following our responsible disclosure policy. For a Fortinet IPS customer, we have provided advanced protections for all of these upcoming vulnerabilities we discovered.

Whether we wish it or not, today the PDF vulnerabilities are making big voice in the industry: JavaScript heap spray technology was finally used in real-world’s exploit (however, I personally think we should see more artistic PDF exploitation method in future), someone is using new encoding method to escape security products. But fortunately, Adobe is also working actively to improve their security process.

Guillaume Lovet contributed to this research