Adobe Reader X’s Sandbox

Posted by Chris Greamo on November 22, 2010

 

Over the past few years, malicious PDFs have become common place and a prefered vector for attackers. 

Last week, Adobe announced the release of Reader X – the much anticipated next major release of their ubiquitous document reader, which includes a new security feature called ”Protected Mode”. Protected Mode is designed to restrict the ability of an attacker who exploits Reader using a malicious PDF to damage, modify, or gain full control of the underlying host. Protected Mode is based on Microsoft’s Practical Windows Sandboxing technology, and like Google’s Chrome browser, implements a sandbox around core components of the product that process untrusted content and, historically, have been vulnerable to exploitation. The sandbox applies a set of more restrictive access control policies to these components, as compared to that of the user, to limit what an attacker can do if he/she successfully exploits Reader using a vulnerability in one of these components. Examples of actions that are limited by the sandbox include the ability to install software, execute processes or create shells, modify system libraries, and shutdown the system form within any code that runs in the Rendering Engine（渲染引擎）. 

In the months since the originally announcement of Protected Mode back in July, Adobe has begun to release details of it’s design on their blog. The following diagram, from Part 2 of the Inside Adobe Reader Protected Mode posting, depicts how Protected Mode implements its sandbox. 

 

Protected Mode separates the Reader’s renderer component, i.e.（id est换言之） the code that parses and renders the PDF content for display, into a separate process running under a lower privileged security principal. API calls to the OS are mediated（斡旋） through a broker（经纪人） running in a separate process – the goal being to remove or limit the ability of the renderer to make these calls directly in the case that the process is exploited and hijacked by an attacker.  

Sandboxing is a step in the right direction – but the devil is in the design and implementation.  Protected Mode is a surgical（外科） sandbox implementation targeting（目标是） really the most egregious（恶劣的） vulnerabilities in a few core components, namely Reader’s renderer and its Javascript engine. Protected Mode will improve the security of Reader against certain types of attacks – those attacks that exploit the rendering engine and attempt to either install malware or monitor user keystrokes（按键）. Adobe engineers themselves enumerate Protected Mode limitations, including: 

• Protected Mode will not prevent unauthorized read access to the file system or registry.
• Protected Mode will not restrict network access.
• Protected Mode will not prevent reading or writing to the clip board（剪贴板）.

 Given these limitations, attackers that exploit these “protected” components will still be able to stay resident in memory and perform damaging activities such as:

• Read and exfiltrate （渗入与潜出(infiltrate and exfiltrate)）data from the registry and/or user’s file system
• Attack other machines and devices on the network
• Use Reader as a stepping stone （垫脚石）to execute other exploits against the host system including exploits against kernel services

To get a flavor of the type of vulnerabilities that we might continue to see against Reader, it is useful to take a look at the exploits against the Google Chrome browser, which follows a very similiar security architecture to Reader X. The following diagram depicts how the sandbox is implemented in the Chrome architecture:

Even with the browser’s rendering engine isolated by a sandbox, we’ve seen approvimately 180 vulnerabilities reported against Chrome in 2010. CVE-2010-3120, CVE-2010-3119, and CVE-2010-3118 are a few examples that could result in exploitation of the host independent of the sandbox. 

The residual exposures left by Adobe’s Protected Mode are significant, and can only be addressed（解决） by a more comprehensive（全面的） solution that confines（限制） attacks against all Reader components, the shared libraries it uses, the kernel, and the network. 

Specifically, a comprehensive security solution needs to provide the following seven traits（特性）: 

1. Host containment（牵制） of processes, the file system, and the OS kernel
2. Network containment to prevent the untrusted instances of the application from accessing file shares or other internal networked systems that contain critical data
3. Near real-time detection of attack activity including 0-days
4. Remediation and reconstitution（修正和还原） of the infected environment to a pristine state
5. Integrity monitoring（完整性监测） of the security mechanisms to prevent subversion（颠覆） of the security mechanisms themselves
6. Ease of use（易用性） and seamless integration（无缝集成） to the host desktop environment
7. Forensics（取证） data capture and reporting

Comparing the Adobe Reader X security capabilities against these requirements: 

While Adobe’s Protected Mode is a step in the right direction for mitigating risk of Adobe Reader, it still leaves significant residual risk on the table for cyber adversaries to exploit. With the release of Adobe Reader X, expect to see new vulnerabilities presented by this additional code to be discovered and exploited by the BlackHat community.