CVE-2018-12794: Using Type Confusion to Get Code Execution in Adobe Reader
September 18, 2018 | The ZDI Research TeamOne of the most common submissions to the ZDI program we see involves bugs impacting PDF documents, and most of these bug reports involve Adobe Reader. We see so many, it takes something special to really catch our attention. The July update for Reader included a patch for CVE-2018-12794/ZDI-18-682. Reported to the program by Sebastian Apelt, the quality of the write-up was too good for us not to share.
The Setup
The underlying cause of the vulnerability is a Type Confusion condition. By constructing an XML Data Package (XDP) template and performing certain JavaScript actions on XML Forms Architecture (XFA) objects, an attacker can force Reader to reference data out of the bounds of a Template object. When successful, code execution occurs within the sandboxed renderer process.
The Vulnerability
The XDP template required to trigger this vulnerability is surprisingly simple:
The vulnerability is triggered by two JavaScript instructions. By appending one subform to another, we can trigger an Out-Of-Bounds (OOB) Read on the underlying Template Object. In this case, the vulnerability occurs when appending one subform referenced by xfa.template and one by xfa.form and then calling <object>.presence = “inactive”;.
After enabling PageHeap, the resulting crash happens on a CMP instruction when reading OOB of the Template object. While the object only seems to be of size 0x140 bytes, we dereference data beyond the buffer boundaries at offset 0x1d0:
Diving Deep
Based on the crash, we know the unique object’s type is 0x7c00. By looking at the symbolized version of acroform.api from Solaris 9.4.1, we can see that this specific type id belongs to the XFATemplateModelImpl object, which is simply the “template” object from the underlying XDP:
Going back to the non-symbolized Windows version of acroform.api confirms that the Template object is of size 0x140 bytes, which is the size of the object referenced OOB from above. The size can be found in a few easy steps:
- Find the static variable 0x7c00 in Acroform.api and look for the XFATemplateModelImpl::Type method:
- Xref gives you XFATemplateModelImpl vtable:
- Xref to vtable start gives you constructor.
- Xref to constructor and scrolling a few lines up will show you the object’s size, which is 0x140 bytes:
Since we cause an OOB read of the Template Object, we can surmise the code expected a different, larger object instead of the Template object, which also indicate this is a type confusion bug. Most likely, the type confusion occurs between the xfa.template and xfa.form objects. While xfa.template is of size 0x140 bytes, the xfa.form object has size 0x270 bytes.
The Exploit
We can’t execute JavaScript code before the Template Object is instantiated, so controlling the crash isn’t trivial. To accomplish this, an exploit would need to resort to controllable allocations and frees during the PDF parsing process or any other controlled data handling before XDP parsing happens. An alternative method to control the crash would be to construct a PDF that contains an attached PDF that triggers the vulnerability. Heap feng shui would have to happen in the “outer” PDF triggering the vuln in the “inner” (attached) PDF. Then again, opening the attached PDF in a way that makes it execute JavaScript code requires elevated privileges, so it might not be effective against most users.
The fact that this crash can be controlled can be observed by executing poc.pdf without PageHeap. The resulting crash will eventually occur due to parts of a Unicode string being read and used as a pointer. The following is a crash output without PageHeap:
Conclusion
If you want to test this out for yourself, the PoC is here. It should work on Adobe Reader versions prior to 2018.011.20040.
Looking at the advisories we’ve published this year, you’ll find a heap of PDF-related cases. Adobe Reader may be the most popular, but plenty of bugs exist in Foxit Reader as well. Throw in built-in PDF renderers in operating systems, and it’s understandable why so many researchers investigate this attack surface.
We’ll be back with other great submissions in the future. Until then, follow the team for the latest in exploit techniques and security patches.