Assessing the Adobe Reader X Sandbox

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 from 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. 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 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.

Chris Greamo is VP of research and development at Invincea.