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