如何使用类型混淆（CVE-2018-12794）在Adobe Reader执行代码

触发该漏洞所需的XDP模板代码相当简单：

该漏洞由两个JavaScript指令触发。通过将一个子表单附加到另一个子表单，我们可以触发对底层模板对象的超界(OOB)读取。在这种情况下，当附加一个xfa引用的子表单时，就会出现漏洞。然后调用 <object>.presence = “inactive”;.

启用PageHeap后，在读取模板对象的OOB时，CMP指令上发生崩溃。虽然对象看起来只有0×140字节大小，但是我们在偏移量0x1d0处取消了对缓冲区边界以外数据的引用：

根据崩溃情况，我们知道唯一对象的类型是0x7c00。通过观察 acroform.api 的符号化版本。在Solaris 9.4.1中，我们可以看到这个特定类型的id属于XFATemplateModelImpl对象，它只是底层XDP的“模板”对象：

回到非符号化的Windows版本的 acroform.api ,我们可以确认模板对象的大小为0×140字节，这是上面引用的OOB对象的大小。我们可以通过几个简单的步骤找到:在 XFATemplateModelImpl::Type method 中 Acroform.api 可以找到静态变量 0x7c00 。

Xref提供XFATemplateModelImpl vtable：

-Xref到vtable start提供构造函数。-Xref到构造函数并向上滚动几行显示对象的大小，即0×140字节：

由于我们导致了对模板对象的OOB读取，所以我们可以推测代码预期的是一个不同的、更大的对象，而不是模板对象，这也表明这是一个类型混淆错误。最有可能的是，类型混淆发生在xfa模板和xfa表单对象之间。而xfa模板大小为0×140字节，即xfa表单对象的大小为0×270字节。

##  Exploit我们不能在模板对象被实例化之前执行JavaScript代码，要知道控制崩溃不是件小事。要实现这一点，需要在PDF解析过程或XDP解析之前的任何其他受控数据处理过程中求助于可控制的分配和释放。控制崩溃的另一种方法是构造一个PDF，其中包含一个附加的PDF，这会触发漏洞。 Heap feng shui 将发生在“外部”PDF中，触发“内部”(附件)PDF中的vuln。然后，以使其执行JavaScript代码的方式打开附加的PDF需要更高的权限，因此它可能对大多数用户无效。通过执行“poc.pdg”可以观察到这种崩溃是可以控制的。即使没有PageHeap。由于要读取Unicode字符串的某些部分并将其用作指针，因此最终会发生崩溃。下面是一个没有PageHeap的崩溃输出：