Anatomy of a PDF Exploit

PDF has become the de-facto standard for formatting print documents. Over the years, it has evolved into a feature rich and very complex system. PDF supports embedded Javascript that can be used for form validation and contains support for different image formats and 3D models, etc. As a result, PDF implementations have numerous vulnerabilities that can be exploit by adversaries to gain control over a user’s computer. Here are a number of CVEs that are currently being exploited in the wild: CVE-2007-5659, CVE-2008-2992, CVE-2009-0927, CVE-2009-2994, CVE-2009-4324, CVE-2010-0188.

In this blog post, we are going to look at current exploitation of CVE-2010-0188: An integer overflow in the parsing of the dot range option in TIFF files. The vulnerability was publicly announced in February 2010. Examples of exploit code are readily available on the Internet and a very good explanation of how the exploit works has been provided by Fortinet.

The exploit described by Fortinet utilizes an AcroForm described in XML. The XML contains an image field with an embedded TIFF image that triggers the vulnerability.

This is all pretty straight forward. However, the other day I encountered a PDF file that was triggering this vulnerability in a more complicated fashion. Let’s take a look at the actual file.

It looks pretty similar to previous TIFF exploit files as that the object of interest is an AcroForm. Here is how object 19 looks like:

1
2

/Fields [18 0 R] /DA (/Helv 0 Tf 0 g ) /XFA [(preamble) 8 0 R (config) 9 0 R (template)
10 0 R (PDFSecurity) 11 0 R (dataset) 12 0 R (xfdf) 13 0 R (form) 14 0 R (postamble) 15 0 R] >>

The template which references Object 10 is particularly interesting:

The form contains a form field named “hunkOar” that has an associated event which is triggered by “initialize”, e.g. right at the beginning. The initialization is being conducted via a pretty long and heavily obfuscated Javascript. After deobfuscation, the Javascript has a surprisingly simple logic:

1
2
3
4
5
6
7
8
9

if (app.viewerVersion < 9.0)
  tiffData = generateBase64EncodedTiff1();
  shellcode = generateShellcode1();
else
  tiffData = generateBase64EncodedTiff2();
  shellcode = generateShellCode2();

sprayMemory(hexDecode(shellcode));
hunkOar.rawField = tiffData;

The data that is being written to the form field is a base64-encoded tiff image that contains an invalid DotRange parameter. Voila exploitation ensues. I did not look at the shell code since I was mostly curious about the ways in which exploits can be set up with PDFs.