Last updated at Wed, 26 Jul 2017 15:27:07 GMT

The last two days have been pretty busy. I have been analyzing the latest Adobe vulnerability. It all began when HD alerted me to a post on Mila Parkour's "contagio malware dump" blog. After giving the blog post a once over, it was pretty clear that she had discovered a live sample of a previously unpublished and currently unpatched vulnerability. The clearest indicator was the screen shot of the Adobe Reader "About" dialog with dropped files showing. Great image! This most definitely piqued my interest.

As a technical person, I then re-scanned to glean the technical details. One awesome piece of information was:

--Accorinding to *REDACTED*, it is "vuln func in cooltype.dll 0x0803dcf9 due 2 incorrect parsing of TTF font and heapspray is done in JS with ROP code (bypasses DEP)"

From this single line, *REDACTED* pretty much laid it all out on the table. Opening CoolType.dll from 9.3.4 up in IDA Pro showed a function where indeed "strcat" was being used. However, I didn't have much more detail at this point, so I asked Mila for the sample via DM and went back to my previous task (working on [r]opcodedb).

An hour or so later, I noticed that Mila had responded and emailed the sample over. With the sample in hand, I proceeded to set a breakpoint and run Reader 9.3.4 with the sample as input. Sure enough, just as *REDACTED* had said, the call was strcat(stack_buf256, user_input). Knowing now just how bad the situation was, I proceeded to do a deeper inspection of the sample.

The File Itself

It appeared to be two PDF files concatenated with a commented 32-bit xor encoded PE. Further investigation showed that the two PDF files were identical except for the "%SIGNATURE: " portion appended to the second one. This could be the indication of some sort of mistake, but we'll likely never know. Since I wasn't interested in the malware portion of this sample, I only briefly glanced at the DLL and moved on.

The PDF Guts

All further analysis took place on only the first PDF within the file (the only PDF). The PDF contains 109 PDF objects, 15 pages, and around 15 fonts. It was also pointed out by @vicheck earlier in the day that the PDF contained JavaScript. Interested in what was in there, I looked closer.

The AcroJS

The document contained an AcroForm JS. That is, JavaScript that executes once a form is loaded.

After pulling the JavaScript object out and doing some fixups, I ended up with a much cleaner version as you can see here. There are several interesting points of which to take notice.

First, the exploit uses AcroJS to detect which version of Adobe Reader is being used to view the document. Which version determines which block of code will be executed next.

Second, a heap spray is used to place ROP data into memory at a guessable address. In this case the author appears to have tried for 0x0d0d0d0d, but I haven't confirmed that just yet. It prefixes the heap spray with a large "ret" sled, similar to a NOP sled, most likely in an attempt to improve reliability when transitioning between the stack bof and the ROP payload. The actual contents of the heap spray differ from one version to the next.

Third, the author uses the nice little page switch trick to navigate to a specific page within the document depending on the Adobe Reader version. This is great for exploitation, since fonts do not get parsed until a page that references them is rendered. The document contains one page for each major version that is "supported".

One odd thing I noticed, which I suspect isn't to uncommon with PDF exploits, is that there were a couple of non-obfuscated strings, some unused variables, and apparent dev/debug stubs for version 6.x and 7.x.

Finally, it is worth mentioning that if the version is too old, or the exploit fails to trigger, a message, "Please update your PDF viewer software." is presented to the user.

The Fonts

Thankfully, @vicheck had pointed out that the problem was in parsing data within the "SING" table of a TrueType font. Further investigation revealed that it was the "uniqueName" field within the SING table structure that was being used in the strcat.

I was a bit curious, so I decided to check the fonts contents for hints about where this font may have came from. I found that this was just a modified copy of the "Vera.ttf" bitstream font, which you can find all over the place. The interesting thing was that the "name" table record had been changed to "SING" and data at the specified offset had been replaced with a specially crafted "SING" table structure.


The Good (Scary?) Part

What I haven't mentioned yet, is that this exploit document does something that I haven't seen in the wild yet. This exploit works on Windows Vista and Windows 7. Unlike the previous exploits, it is not dependent on a hardcoded Windows XP syscall. Additionally, it uses a previously unpublished technique to bypass ASLR.

The gadgets that are used for this ROP payload come from a module named "icucnv36.dll". This module does not support ASLR (nor does it opt in to DEP, although that is largely irrelevant).

NOTE: The author of the exploit had to jump through some hoops to get this module loaded. I haven't determined what those hoops are at this point, but it is on my immediate TODO. I will update our exploit in SVN with that technique once I get it working.

You can protect yourself from exploits using the "icucnv36.dll" technique by using cacls to deny all access to the module. Unfortunately, there are two problems with this workaround. First, it won't prevent exploitation completely. Second, Adobe Reader may have issues opening PDF documents that legitimately need this module.

Conclusion

So here we are, around 24-48 hours later. Adobe has already confirmed the issue and released an advisory.

SANS released a blog. Please note that I don't believe that this is a "loud exploit". Contrary to their blog, there doesn't appear to be any good news here. Standard precautions do apply though, so don't open those PDFs!

It sure seems like the attackers are feeling the pressure of Adobe's upcoming sandbox.

Here is a summary of what I've found:


  • Vulnerability Type: Stack Buffer Overflow
  • Bypasses DEP: Yes
  • Bypasses ASLR: Yes
  • Exploit Requires JS: Yes
  • Vulnerability Requires JS: No