PDF漏洞(CVE-2018-12794)浅析

5月 7,2019by admin

漏洞简介
 
CVE-2018-12794属于类型混淆漏洞,产生漏洞原因是通过构建XML数据包(XML Data Package,XDP)模版,并对XML表单体系结构(XML Forms Architecture,XFA)对象执行某些JavaScript操作,攻击者就可以强制Adobe Reader从模版对象的边界引用数据。
 
2018年7月份,Adobe补丁更新:
 

 
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对象的函数进行处理,造成了类型混淆漏洞。