CVE-2018-12794: Using Type Confusion to Get Code Execution in Adobe ReaderSeptember 18, 2018 | The ZDI Research Team
One 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 XDP template required to trigger this vulnerability is surprisingly simple:
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
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
Acroform.api and look for the
- Xref gives you
- 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
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.form objects. While
xfa.template is of size
0x140 bytes, the
xfa.form object has size
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:
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.