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对象，参考《SyScan3602016-_Pwning_Adobe_Reader_with_XFA》报告
中给出的关于XFA内部对象的识别办法获取Type-IDs。使用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对象的函数进行处理，造成了类型混淆漏洞。
参考资料
https://github.com/siberas/arpwn/blob/master/slidedecks/SyScan360_2016_-_Pwning_Adobe_Reader_with_XFA.pdf
https://xz.aliyun.com/t/4262
http://blogs.adobe.com/formfeed/2009/03/xfa_30_presenceinactive.html
更多漏洞播报：四维创智
转载于:https://blog.51cto.com/13694685/2391047