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?
A 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:
- 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.
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
In-scope goals: Adobe Reader’s sandboxing architecture primarily focuses on preventing the attacker from doing two things:
- Installing malware on the user’s machine
- 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.
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.
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