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. _
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
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,
Given these limitations, attackers that exploit these “protected”
components will still be able to stay resident in memory and perform
damaging activities such as:
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:
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
_Chris Greamo is VP of research and development at Invincea. _