A Look Back at PDF Vulnerabilities

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