Adobe X沙箱

一、Adobe X沙箱简介

Adobe Reader X自从引入沙箱以来，对其攻击的难度就提高了很多。Reader X的沙箱是基于Google的Chrome沙箱，Chrome是开源的，Reader X和Chrome的代码有很大程度上的相似。

Adobe Reader X以及后续版本，在启动的时候会有两个进程，这两个进程的名字都叫AcroRd32.exe，是一对父子进程。其中父进程一般称为Broker进程，子进程称为SandBox进程，二者其实是同一个可执行文件AcroRd32.exe，只不过启动参数不同（参考文章《PLAYING IN THE READER X SANDBOX》）

图1：父子进程Broker.exe和SandBox.exe

Broker进程启动SandBox进程时修改了SandBox进程中的一些关键API，以User32! GetClipboardFormatNameA函数为例

图2：修改前的User32! GetClipboardFormatNameA函数

图3：修改后的User32! GetClipboardFormatNameA函数

在 SandBox进程中调用一些系统API的时候，会跳转到Adobe Reader自己的函数中(如图4中的JMP 00990270)，并通过IPC调用把要执行的指令传给Broker进程，Broker进程来决定API是否被调用，最终通过IPC把结果返回给SandBox进程。

当打开一个PDF文件时，SandBox进程作为PDF文件的解释器解析PDF文件格式及其中的JS脚本，就算利用漏洞绕过了SandBox进程执行shellcode，由于有Broker进程的缘故，shellcode的功能也十分有限，这给了Adobe Reader极大的安全保障。Reader X逻辑关系如图4。

图4：Reader X逻辑关系图

二、漏洞利用——CVE_2013_0640 + CVE_2031_0641

1.    CVE_2013_0640

位置：作用于SandBox进程

成因：堆分配错误导致的可读写任意字节漏洞

效果：可在SandBox进程中执行shellcode

2.    CVE_2013_0641

位置：作用于Broker进程

成因：SandBox与Broker进程IPC通信漏洞

效果：可在Broker进程中执行shellcode

二者结合可突破Adobe Reader X，效果如图5。

图5：CVE_2013_0640 + CVE_2031_0641 突破Adobe Reader X

三、Adobe X 漏洞挖掘简介

1.     CVE-2013-0641简介

1)     前提假设：已获取SandBox进程控制权

2)     漏洞成因：IPC Call
         SandBox和Broker进程是通过IPC Call通信的，其每个IPC Call都有一个TagID标识调用的函数名。Broker进程根据TagID确定调用的是什么函数，如TagID = 0×74则Broker进程认为当前要调用的是GetClipboardFormatNameA 函数，TagID = 0×73则Broker进程认为当前要调用的是GetClipboardFormatNameW 函数。

当我们用TagID = 0×73 调用GetClipboardFormatNameA时会导致Broker进程的堆溢出，在下次IPC Call时可获取Broker进程控制权，如图6,7,8。（详情可参考南京翰海源的分析http://blog.vulnhunt.com/index.php/2013/02/21/cve-2013-0641-analysis-of-acrobat-reader-sandbox-%20escape/）

图6：TagID=0×74 发起GetClipboardFormNameA调用

图7：TagID=0×73 发起GetClipboardFormNameW调用

图8：TagID=0×73 发起GetClipboardFormNameA调用

  2. IPC Call 漏洞挖掘

Broker进程的逃逸是突破Adobe X的关键，Adobe的IPC Call可能还存在类似CVE-2013-0641的漏洞。若要对此类漏洞挖掘，则首先要获取Adobe所有的TagID，函数参数列表并把TagID对应到具体的Windows API上，可以通过静态分析AcroRd32.exe获取相应的信息（以下内容参考自 ADOBE SANDBOX WHEN THE BROKER IS BROKEN, CanSecWest 2013）。

1) 通过一已知API（InternetGetCookieA）的交叉引用表定位其TagID，如图9-13。

图9：从导出表查找函数InternetGetCookieA的地址

图10：定位InternetGetCookieA函数

图11：查看InternetGetCookieA的交叉引用表

图12：内存搜索交叉引用表中第一下地址，并获取到唯一值

图13：查看内存搜索结果附近数据

Broker进程对每一个可处理的API Call都要调用同一个函数初始化， 大括号中的数据结构A为初始化函数传入的参数。

由图可知InternetGetCookieA与48B190，0×68是一一对应的。

2) 获取所有TagID和函数参数列表，如图14-16。

图14：获取数据结构A的交叉引用表

图15：查看调用A的函数(Call _text_413DD0)，此函数即为所有API Call都需调用的初始化函数

图16：查看Call _text_413DD0的交叉引用表

从Call _text_413DD0的交叉引用表中可以找到所有类似于A的数据结构，从而定位所有TagID，如图17-18。

图17：点击交叉引用表

图18：获取TagID的数据结构

3）将TagID对应到Windows API

Adobe中有个函数是用来开启API拦截的，此函数可对某个指定的API是否开启拦截。可通过InternetGetCookie函数找到此拦截函数，如图19,20。

图19：内存搜索InternetGetCookieA函数

图20：call _text_42A580即为开启API拦截的函数的地址

通过call _text_42A580定位函数名和TagID的关系，如图

图21：函数call _text_42A580

图22：Call _text_42A580的交叉引用表

图23：从交叉引用表中获取函数名与TagID对应关系

3. 自动化脚本测试

      按上述思路可用脚本获取所有TagID，对应到函数名和相应参数，以便进一步的漏洞挖掘。