Digging Into the Sandbox-Escape Technique of the Recent PDF Exploit

As promised in our previous blog entry for the recent Adobe Reader PDF zero-day attack, we now offer more technical details on this Reader “sandbox-escape” plan. In order to help readers understand what’s going on there, we first need to provide some background.

Adobe Reader’s Sandbox Architecture

The Adobe Reader sandbox consists of two processes: a high-privilege broker process and a sandboxed renderer process; the latter is responsible for rendering the PDF document.


"Click the image to get it larger"

We copied the preceding image from Adobe’s ASSET blog. The renderer process has restricted read/write access to the file system, registry, and named objects. Most of the native OS API calls will go through the interprocess communication (IPC) mechanism to the broker process. For example, you can find more details in the following image to see how a native API call (CreateFile) originates from the sandbox process and how the broker process eventually takes over as a proxy.



Actually, the Reader sandbox’s IPC is implemented based on Google Chrome’s IPC shared-memory mechanism. The broker process creates a 2MB shared memory for IPC initialization, the handle of the shared memory is duplicated and transferred to the sandboxed process, and all the communications leverage this shared memory.

The API call request from the sandboxed process is stored in an IPC channel buffer (also called CrossCallParams or ActuallCallParams). The structure of the buffer is defined as the following format (from crosscall_params.h):



Here are some explanations for the fields:

• The first 4 bytes, the “tag,” is the opcode for which function is being called

• “IsOnOut” describes the data type of the “in/out” parameter

• “Call return” has 52 bytes. It’s a buffer used to fill the returning data from the IPC server.

• “Params count” indicates the number of the parameters

• The parameter type/offset/size info indicate the actual parameters
The parameter type is an enum type, s defined as follows:



Escaping the Sandbox

The sandbox escape in this zero-day exploit is due to a heap-based overflow vulnerability that occurs when the broker process handles the call request of the native API “GetClipboardFormatNameW.” The tag id for this API is 0×73. Here is the ActuallCallParams (IPC channel buffer) memory structure for the request in the exploit:



As marked by different colors above, the first DWORD is the tag id (0×73), and there are only two parameters for this API call (as indicated by the blue DWORD). The yellow DWORDs are the parameter types: Type 6 means INOUTPTR_TYPE and type 2 means ULONG_TYPE. The red DWORDs are the sizes for these parameters, so the first parameter has 0x9c bytes with the “in/out ptr” type and the second parameter has 4 bytes with the “long” type.

Let’s take a look at the definition of the parameters for the GetClipboardFormatNameW API.



According to the preceding definition, the GetClipboardFormatNameW call would look like this:

GetClipboardFormatNameW(0xc19a, “BBBBBBBBBB……”, 0x9c);

At first sight, this function call looks normal, with nothing malicious. Unfortunately, there are two issues that will lead to a heap overflow condition. First, Adobe Reader allocates the heap memory based on “cchMaxCount,” while the correct size should be “cchMaxCount * sizeof(WCHAR)” as this is a Unicode API. In our case, the allocation size is only 0x9c; that is incorrect. Second, the lower-level native API NtUserGetClipboardFormatName() called by GetClipboardFormatNameW() is using cchMaxCount*sizeof(WCHAR) as its “length” parameter when copying a string to the heap buffer. At this point the heap overrun happens!

There is a trick to trigger this heap overflow: Just pay attention to the first parameter. From the MSDN description, the parameter “format” is used to retrieve the type of the format. So if we can pass in advance a format ID that requires a longer buffer space, then later when the broker calls the GetClipboardFormatNameW() to retrieve the format, it will trigger the overflow.

In this sandbox-escaping exploit, the malware calls RegisterClipboardFormatW() to register a different format name, which is much longer than 0x9c bytes. Finally, an object (vtable) on heap will be overwritten. However, the story is not over yet. In order to achieve reliable exploitation, a heap spray inside the broker process is needed. The attacker did this in a very smart way, he or she leveraged the “HttpSendRequestA” function (tag id 0x5d). See the following dumped memory for this function call request.



Because the fourth parameter (lpOptional) has the type VOIDPTR_TYPE (its address and size are highlighted in red) in the exploit, the attacker passes the buffer size 0x0c800000 (the second red section). Because the size is huge, when the IPC server calls ReadProcessMemory API to read the buffer, the broker process’ heap memory will be sprayed with attacker-controlled data at a predictable memory location.

The ASLR- and DEP-bypassing part is very easy because the module base addresses of the broker process and the sandboxed process are same. The attacker can directly use the ROP code chain to defeat both ASLR and DEP.

Adobe has now released the official patch for these critical vulnerabilities. As always, we strongly suggest that users apply the patch as soon as possible. For McAfee customers, you’ll find our solutions in our previous post.

Thanks again to Bing Sun, Chong Xu, and Haifei Li for their help with this analysis.


Orginal article: Wednesday, February 20, 2013 at 5:37pm by Xiao Chen

Analyzing the First ROP-Only, Sandbox-Escaping PDF Exploit

The winter of 2013 seems to be “zero-day” season. Right after my colleague Haifei Li analyzed the powerful Flash zero day last week, Adobe sent a security alert for another zero-day attack targeting the latest (and earlier) versions of Adobe Reader. Unlike Internet Explorer zero-day exploits that we have seen in the past, this Reader zero-day exploit is a fully “weaponized” affair. It contains advanced techniques such as bypassing address-space layout randomization/data-execution prevention by using memory disclosure and a sandbox escape in the broker process. In this blog we will give a brief analysis of the exploitation.

The malicious PDF file used in the this exploitation consists mainly of three parts:

•Highly obfuscated JavaScript code, containing heap-spray data with a return-oriented programming (ROP) payload and the JavaScript code to manipulate Adobe XML Forms Architecture (XFA) objects to trigger the vulnerability
•A flat-encoded XFA object
•An encrypted binary stream, which we believe is related to the two dropped DLLs
The exploitation has two stages. The first-stage code execution inside the sandboxed process happens in the AcroForm.api module. A vtable pointer will be read from the attacker-controlled heap-spray area and later will be used in the call instruction.

This exploit can leak the base-module address of AcroForm.api. The embedded JavaScript code is used to detect the current version of Adobe Reader, and all the ROP payload can be built at runtime.

Most important, there is no traditional shellcode at all! All the required shellcode functions are implemented in the ROP code level. That means most emulation-based shellcode-detection techniques will fail in detecting such an exploitation, because those techniques see only a bunch of addresses within a legitimate module. It’s similar to the old iOS jailbreak exploit that can be used to defeat the iOS code-signing enhancement.

The ROP shellcode first decrypts an embedded DLL (D.T) in memory and drops it to the AppData\Local\Temp\acrord32_sbx folder. Then, it loads the DLL into the current process. After that, the hijacked thread suspends itself by calling Kernel32!Sleep API. When D.T runs in the sandboxed process, it drops other DLLs (L2P.T, etc.) and is ready to escape the sandbox by exploiting another Adobe vulnerability.

The second-stage code execution occurs inside the broker process. The destination of the call instruction can also be controlled by the attacker.

The second-stage ROP shellcode is very short. It simply loads the dropped DLL L2P.T and goes into a sleep state. At this point, the exploit has already successfully broken out of the Reader sandbox because the attacker-controlled code (L2P.T) managed to run in the high-privileged broker process.

This is the first in-the-wild exploit we have seen that has fully escaped the sandbox. Previously, we had only heard of the possibility of full sandbox escaping at a top hacking competition such as pwn2own. Besides the complicated exploitation portion, this exploit also uses multiple evasion techniques such as highly obfuscated JavaScript, ROP-only shellcode, and multistaged encrypted malware to bypass network and endpoint security detection and protection. After succeeding, the exploit code exits the hijacked process and creates new processes to render a normal PDF file. The exploitation happens in a split second; thus the victim who opens that original malicious PDF file will not observe any abnormal behavior.

We will continue our analysis and provide more detail later on the sandbox escape. For now, we strongly recommend that all Reader users enable protected view and disable JavaScript (Edit -> Preferences -> JavaScript -> Uncheck the “Enable Acrobat JavaScript” option) until Adobe releases a patch.

For McAfee customers, we have released signature 0x402e0600 “UDS-HTTP: Adobe Reader and Acrobat XFA Component Remote Code Execution” for the Network Security Platform appliances. Also, the generic buffer overflow prevention (Sigs 6013 and 6048) feature on our HIPS product will help to stop related attacks.

Thanks to Bing Sun, Chong Xu, and Haifei Li for their help with this analysis.


Orginal article: Friday, February 15, 2013 at 4:05pm by Xiao Chen