一、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，对应到函数名和相应参数，以便进一步的漏洞挖掘。