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。