如何进行PDF漏洞CVE-2018-12794的浅析

如何进行PDF漏洞CVE-2018-12794的浅析，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

漏洞简介

CVE-2018-12794属于类型混淆漏洞，产生漏洞原因是通过构建XML数据包（XML Data Package，XDP）模版，并对XML表单体系结构（XML Forms Architecture，XFA）对象执行某些JavaScript操作，攻击者就可以强制Adobe Reader从模版对象的边界引用数据。

2018年7月份，Adobe补丁更新：

漏洞基本信息

漏洞ID：CVE-2018-12794

漏洞名称：PDF类型混淆漏洞

漏洞类型：远程代码执行

威胁类型：类型混淆

影响版本：影响2018.011.20040及之前版本

漏洞测试

系统环境：Win7 32

Adobe Reader：2018.011.20040

PoC：https://github.com/thezdi/PoC/tree/master/CVE-2018-12794

PoC分析

XML Data Package（XDP）是Adobe Systems创建的XML 文件格式。该格式允许将PDF内容或Adobe XML Forms Architecture（XFA）资源打包在XML 容器中。XDP符合XML 1.0的规范，可以作为独立文档，也可以在PDF文档中携带。XDP提供了一种在XML容器中打包表单组件的机制，XDP还可以打包PDF文件以及XML表单和模板数据。

第1个object流对象里面的XFA（XML Forms Architecture）对象会执行Java代码，该代码会操作sub1和sub2，先将sub1添加为xfa.template对象，sub2添加为xfa.from对象，然后将sub2附加到sub1。

最后执行Java代码将o2的presence属性设置为inactive ，该属性的含义为隐藏对象并将其从事件处理中排除。在执行该操作的时候将触发crash。

调试分析

通过gflags 开启页堆后，用Windbg附加Adobe Acrobat DC打开PoC文件。程序会停在发生crach的位置。

从上面调试信息中可以看到，异常出现在AcroForm.api模块，ecx的值异常导致程序crash，通过栈回溯可以定位到crash的上一层函数AcroForm!PlugInMain+0x979f1，反汇编该函数并观察ecx的值（ecx的值是直接传入crash函数使用）。

反汇编代码后发现ecx的值来自[eax+esi*8]，而esi只是一个偏移且为0，故ecx的值与eax有关，来自[edi+1d4h]。该地址的值是一些字符串，由此推测，是把该字符串的值当成了指针来引用，从而导致crash。

经多次调试发现[edi+1d4h]每次的值都不同，这个地址的值是未知的，如下图。

使用堆命令查看edi所在的空间大小为140h，猜测是一个对象指针或者一块申请的内存空间，而[edi+1d4h]显然已经是越界访问。

从代码中知道为XFA对象，使用uf poi(poi(对象地址)+8)的命令可以显示出Type-IDs。

类型为7C00h，说明了该堆块保存的就是一个XFA对象。

通过交叉引用得到 XFATemplateModelImpl 的虚表,再通过交叉引用构造函数就能找到这个对象大小为 140h 字节。

在XFATemplateModelFactoryImpl::newModel函数中可以看到申请了140h字节的空间，从函数名猜测这里是new一个大小为140h的Template对象。

在虚表进行交叉引用可定位到相应的初始化Form对象的地址，Form对象申请的空间大小是270h， [edi+1d4h]的地址实际应该是读取的Form对象中的值，Template对象大小是140h，所以漏洞的根本原因是代码在处理Template对象时使用了Form对象的函数进行处理，造成了类型混淆漏洞。

看完上述内容，你们掌握如何进行PDF漏洞CVE-2018-12794的浅析的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注行业资讯频道，感谢各位的阅读！