poi xml模板 操作pdf_PDF漏洞（CVE201812794）浅析

 漏洞简介 

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