Archive for October, 2010

Inside Adobe Reader Protected Mode – Part 2 – The Sandbox Process

We continue our technical tour of Adobe Reader Protected Mode with a closer look at the sandbox process. (Check out part one of this series, if you missed it.) In today’s blog post we will look at all of the different ingredients the Windows operating system provides for a sandbox and see how those ingredients are used in the sandbox process to restrict access.

Figure 1 - Sandbox Process

Figure 1 - Sandbox Process

Process Level Granularity

For a sandboxed process, adhering to the principle of least privilege means that in many cases, the process can’t do much besides talk to the broker process. On Windows, code cannot perform any form of input-output task (I/O) to disk, keyboard, or screen without making a system call. Most system calls cause Windows to perform some sort of security check. The Adobe Reader sandbox process runs in an environment where these security checks fail for restricted actions.

The security check point of failure acts like a security fence, containing the sandboxed code. For Adobe Reader, that means limiting the code’s functionality by imposing a well-defined set of restrictions provided by the Windows security model. These include:

  • Limiting the token for the sandbox process:
    • Denying or restricting security identifiers (SIDs)
    • Removing privileges
  • Assigning the sandbox to a job object with restrictions
  • Running the sandbox process at low integrity on Windows Vista, Windows 7, and Windows Server2008

The Adobe Reader team uses these Windows operating system features to mitigate certain classes of attacks to help defend against attempts by a malicious PDF file seeking to exploit a vulnerability in Adobe Reader.

Restricting Security Identifiers (SIDs) and Privileges

One layer of protection is provided by restricting permissions to read, write, execute, etc. on the relative trustworthiness of the process owner. Identifying the owner’s role-specified rights and privileges occurs via a security access token when the user logs on. In Windows security parlance, the Reader user is a “trustee.” Any process the trustee invokes will execute in a security context which is partially defined by the access token.
The access tokens consists of two primary components: Security Identifiers (SIDs) and privileges. Windows fully describes the security context of every process that runs on behalf of the trustee by setting these two components. Reader modifies that context for sandboxed processes as follows:

  • Denying or restricting SIDs. Target process SIDs are modified by:
    • Marking all SIDs DENY_ONLY except for BUILTINUsers, Everyone, User’s Logon SID, NTAUTHORITYINTERACTIVE.
    • Adding the following SIDs to the restricting SID list: BUILTINUsers, Everyone, User’s Logon SID, NTAUTHORITYRESTRICTED.
  • Adding a low integrity level SID (for Vista, Windows 7, and Windows Server 2008 only).
  • Removing privileges. All privileges except the SetChangeNotifyPrivilege are removed from target process access tokens.

Through these methods, Adobe Reader further restricts the access token to limit access to securable objects or perform privileged operations. 

Figure 2 - Deny SIDs, Restricted SIDs, Privileges removed

Figure 2 - Deny SIDs, Restricted SIDs, Privileges removed

Job Objects

For certain tasks, groups of target processes can be grouped and managed as a unit in a job object. Windows Job objects are securable objects that control its processes attributes. Therefore, a job object can enforce additional global restrictions on all processes with which it is associated. Like other securable objects, access to job objects are controlled with a security descriptor. The Adobe Reader sandbox processes are placed in a job with the following restrictions: 

  • ActiveProcess – ActiveProcess limit of 1
  • Desktop Limited – Inability to create/switch to desktops
  • Display Settings – Inability to call ChangeDisplaySettings
  • Exit Windows – Inability to exit Windows via ExitWindows(Ex)
  • USER Handles – Inability to use USER handles owned by processes not associated with the same job
  • System Parameters – Inability to change system parameters via the SystemParametersInfo function
  • Administrator Access – Prevents any process in the job from using a token that specifies the local administrators group

These limitations prevent malicious code in the sandbox from tampering with different parts of the operating system.

Figure 3 - Job Object Limits

Figure 3 - Job Object Limits

Low Integrity

The Windows integrity mechanism is a component of the Windows architecture that restricts application access permissions by assigning integrity levels (essentially trustworthiness markers) to all processes and securable objects. While not a silver bullet on its own, the addition of the integrity mechanism starting with Windows Vista was a huge leap forward for implementing the sandbox because it enforces access restrictions to so many different parts of the operating system. Resource managers such as the file system block less trustworthy processes from modifying objects of higher integrity. For Adobe Reader, target processes run as a low integrity processes which prevents them from communicating with processes of higher integrity. This mechanism provides a form of mandatory access control for process-level granularity. Since integrity is a feature that’s only available on Windows Vista and later, it means that the sandbox on these platforms offer stronger protection than the sandbox on Windows XP. 

Process Explorer

The screen shots in figure 2 and figure 3 above are from the Process Explorer tool. A quick way to assess the operating system protections used by a sandbox in Windows is to look at the sandbox process in Process Explorer. For fun, compare the ‘Security’ and ‘Job’ tabs in Process Explorer for different applications that claim to have a sandbox or protected mode and see how they stack up against each other.

No Separate Desktop for Adobe Reader Protected Mode

The third part of David LeBlanc’s Practical Windows sandboxing recommended putting your sandboxed process into a separate desktop, because there is very little security within a Windows desktop. The Adobe Reader engineering team evaluated the possibility of running Adobe Reader in a separate desktop but came to the conclusion that doing so would require significant architectural changes that would delay our ability to provide an Adobe Reader sandbox until well into 2011. (Building a sandbox into an application as complex as Adobe Reader has been compared to adding a basement to a 20-story building after it’s already been erected.)
So, the challenge became:  Could we provide nearly all of the mitigations a separate desktop provides using other techniques?  The answer is: Yes, we can. This section describes how we did it in detail, as well as the limitations.

(A special word of thanks to David LeBlanc of the Microsoft Office team, and Nicolas Sylvain of the Google Chrome team for their help exploring the alternatives.)

Shatter Attack

One attack that a separate desktop would mitigate against is known as the Shatter Attack. To prevent shatter attacks, we need to ensure our sandbox process cannot send window messages to windows owned by other processes, unless explicitly granted permission to do so.
We were able to mitigate against these attacks with Adobe Reader Protected Mode on Windows XP SP3 and higher using two techniques:

Our job object sets the UILIMIT_HANDLES restriction.  This prevents the sandboxed process from accessing user handles created by processes not associated with our job.

On Windows Vista and later, we also run the sandboxed process at low integrity. With User Interface Privilege Isolation (UIPI), processes are prevented from sending messages to windows owned by processes running at a higher integrity level.

Abuse of SetWindowsHookEx

SetWindowsHookEx is a powerful Windows API that can allow malware to insert itself into any process running in the same desktop. Running your sandboxed process in a separate desktop would prevent this from happening.

Despite not running in a separate desktop, we were able to mitigate against these attacks with Adobe Reader Protected Mode using these techniques:

  • Our job object sets the UILIMIT_HANDLES restriction. This prevents the sandboxed   process from setting hooks into processes not associated with our job.
  • The Adobe Reader sandbox is running with a restricted token. Due to the restricted token, Windows does not trust our process to set a hook.
  • On Windows Vista and later, we also run the sandboxed process at low integrity. With User Interface Privilege Isolation (UIPI), processes are prevented from setting hooks into processes running at a higher integrity level and cannot inject DLLs using SetWindowsHookEx.

Transient Key Loggers

Key logging malware attempts to steal valuable information by logging keystrokes in other processes. Ideally, using a separate desktop for the sandboxed process would prevent this type of attack.

Despite not running in a separate desktop, we were able to mitigate against these attacks with Adobe Reader Protected Mode, but only on Windows Vista, Windows Server 2008 and Windows 7:

  • On Windows Vista and later, we also run the sandboxed process at low integrity. With User Interface Privilege Isolation (UIPI), processes are prevented from reading key strokes in processes running at a higher integrity level.

Screen Scraping Attacks

Running the sandboxed process on a separate desktop can mitigate against malware that attempts to steal information by scraping the screen.  

Given the UIPI/restricted-token/handles restriction capabilities of our sandbox, we can mitigate against the screen scraping attack without running in a separate desktop. Unfortunately, we could not implement it this time around because lot of our code in Adobe Reader requires explicitly giving handle access to the desktop window handle. We plan to explore this further in a later dot release.

Conclusion

This concludes the detailed view of the Adobe Reader sandbox process and how it leverages the Windows OS security model to thwart persistent malware and transient key logger type of attacks. In the next post, we will explore the broker process in more detail. Special thanks to Tom Keetch for providing some valuable insight into the details of some low-level access controls used by the sandbox.

On a related note, we just added a session titled “Sandboxing Adobe Reader: Protected Mode” to the schedule for users attending Adobe MAX 2010, held in Los Angeles from October 23-27, 2010. Speakers will be Suchit Mishra, Acrobat lead security researcher and Joel Geraci, Acrobat technical evangelist. For details, visit: https://max.adobe.com/schedule/by-session/sandboxing-adobe-reader-protected-mode/1f420056-b205-4729-b135-d98d72c8c658.

-Liz McQuarrie, Ashutosh Mehra, Suchit Mishra, Kyle Randolph, and Ben Rogers

Inside Adobe Reader Protected Mode – Part 1 – Design

Introduction

Kyle Randolph here, along with the security team for the Acrobat family of products, including Adobe Reader. This is the first post in a multi-part series about the new sandboxing technology used in the Adobe Reader Protected Mode feature that was announced back in July. We will take a technical tour of the sandbox architecture and look at how its different components operate and communicate in ways that will help contain malicious code execution. 

What is sandboxing?

sandbox is a security mechanism used to run an application in a confined execution environment in which certain functions (such as installing or deleting files, or modifying system information) are prohibited. In Adobe Reader, “sandboxing” (also known as “Protected Mode”) adds an additional layer of defense by containing malicious code inside PDF files within the Adobe Reader sandbox and preventing elevated privilege execution on the user’s system. 

The Adobe Reader sandbox leverages the operating system’s security controls to constrain processes execution to the principle of least privilege. Thus, processes that could be subject to an attacker’s control run with limited capabilities and must perform actions such as accessing files through a separate, trusted process. This design has three primary effects:

  • All PDF processing such as PDF and image parsing, JavaScript execution, font rendering, and 3D rendering happens in the sandbox.
  • Processes that need to perform some action outside the sandbox boundary must do so through a trusted proxy called a “broker process.”
  • The sandbox creates a new distinction of two security principals: the user principal, which is the context in which the user’s logon session runs, and the PDF principal, which is the isolated process that parses and renders the PDF. This distinction is established by a trust boundary at the process level between the sandbox process and the rest of the user’s logon session and the operating system.

The goal of this design aspect is to process all potentially malicious data in the restricted context of the PDF principal and not in the context of the fully privileged user principal. As shown in the diagram below, Inter-process communication (IPC) is used when the sandbox needs an action performed by the broker as the user principal instead of the PDF principal, such as calling an OS API or getting write access to a file.

Sandboxing is relatively new for most enterprise applications because it is difficult to implement in mature software (i.e. software with millions of lines of code) that is already deployed across a virtually limitless number of environments. A few recently shipped products that demonstrate the sandboxing proof of concept include Microsoft Office 2007 MOICE, Google Chrome, and Office 2010 Protected View. The challenge is to enable sandboxing while keeping user workflows functional without turning off features users depend on. The ultimate goal is to proactively provide a high level of protection which supplements the mitigation of finding and fixing individual bugs.

Design Principles

The sandbox was designed with several security best practices in mind:

  • Leverage the existing operating system security architecture: The Adobe Reader sandbox relies on Windows operating system security features such as restricted tokens, job objects and low integrity levels.
  • Leverage existing implementations: The Adobe Reader sandbox builds on the Google Chrome sandbox and also took Microsoft Office 2010 Protected Mode into consideration.
  • Adhere to the principle of least privilege: Every process (executable code) can only access the resources necessary to perform its legitimate purpose.
  • Consider all sandbox data untrusted: Assume all data communicated out of the sandbox is potentially malicious until it has been validated. 

 
Mitigations Provided by the Reader Sandbox

For the sake of this discussion, let’s assume that an attacker has achieved arbitrary code execution by exploiting an unpatched vulnerability in the Adobe Reader renderer and is able to convince the user to click on a malicious PDF file delivered via an e-mail attachment or to click on a link to a malicious PDF file hosted on a website controlled by the attacker. Historically, just double-clicking and rendering this PDF file could lead to total compromise of the user’s machine. Say, for example, the attacker knows and is able to exploit an unpatched buffer overflow vulnerability in the Adobe Reader JavaScript APIs or an integer overflow vulnerability in the Fonts components. Once that’s done, it’s fairly trivial for the attacker to lure victims into opening the weaponized PDF file by deploying it via a spam e-mail/advertisement or hosting it on a popular website.

In-scope goals: Adobe Reader’s sandboxing architecture primarily focuses on preventing the attacker from doing two things:

  1. Installing malware on the user’s machine
  2. Monitoring the user’s keystrokes when the user interacts with another program

If the attacker succeeds in circumventing the above mentioned in-scope goals, then he or she can cause serious damage to the user. For example, once the attacker is able to install malicious software on the user’s computer, he or she could end up having write/update/delete access to the file system and registry and might attempt to install a botnet client that receives commands over the network and engages in coordinated attacks across the network. In the other scenario where the attacker is able to monitor the user’s keystrokes, he or she can attempt to steal confidential and sensitive information, such as passwords and credit card numbers.

So simply put, the Adobe Reader sandbox–much like the Google Chrome Sandbox–does not allow the attacker to install persistent malware or tamper with the user’s file system and thwarts the attacker from taking control of the user’s machine. This ties back to the design principle of least privilege: an exploit can possibly run within the application but cannot do anything malicious to the user’s machine because its access is completely blocked by the highly restrictive sandbox environment. In conclusion, this greatly reduces the attack surface of the Adobe Reader software application.

Limitations

The sandbox’s reliance on the operating system means that it could potentially be subject to its flaws. Like the Google Chrome sandbox, the Adobe Reader Protected Mode sandbox leverages the Windows security model and the operating system security it provides. This intrinsic dependency means the sandbox cannot protect against weakness or bugs in the operating system itself. However, it can limit the severity of such flaws when code executes inside the sandbox, since the sandbox blocks many common attack vectors.

Our first version of sandboxing is not designed to protect against:

Unauthorized read access to the file system or registry. We plan to address this in a future release.

Network access. We are investigating ways to restrict network access in the future.

Reading and writing to the Clipboard

Insecure operating system configuration

The last ingredient for a Windows sandbox according to the Practical Windows Sandboxing recipe is to use a separate desktop for rendering the user interface (UI). We chose not to use a separate desktop due to the complexity of the change in how Adobe Reader renders its UI. Instead, we enumerated the attack vectors that sharing a desktop leads to, shatter attacks and SetWindowsHookEx DLL Injection attacks. These attack vectors were mitigated through alternative means, using low integrity and limits in the sandbox job object, which will be discussed in more detail in our next post.

Conclusion

This concludes the overview of the Adobe Reader Protected Mode sandbox architecture and limitations. In future posts, we will explore the sandbox process and the broker process in more detail, as well as their inter-process communication (IPC) mechanisms. Finally, we will comment on the security testing we use to validate the security of the Adobe Reader sandbox.

-Liz McQuarrie, Ashutosh Mehra, Suchit Mishra, Kyle Randolph, and Ben Rogers