Adobe Reader X: is the sandbox feature effective?
Date : May 03, 2012
In November 2010, Adobe released version X of its PDF reader: Adobe Reader. This new version added a security protection to the reader by integrating a "sandbox" feature that limits the actions that a malicious PDF file can perform. This is a major security enhancement for Adobe Reader. More than a year after that new feature appeared, we recap the situation about its effectiveness.
1) Introducing the Adobe Reader Sandbox feature
This feature is officially called "Protected Mode" in Adobe Reader, and "Protected View" in Adobe Acrobat (see paragraph 3 for further explanation about Adobe Acrobat). It only exists for Windows versions of the products (the Mac OSX or Linux / Unix versions do not support that feature). It forces Reader execution in a controlled environment in which:
- the Reader has restricted privileges (loss of some Windows privileges),
- some operations are prohibited. For example any write attempt (such as file creation or modification of the Windows Registry) are caught and rejected. There are however exceptions to this behaviour, defined by the way of "Policies" specified in the "ProtectedModeWhiteList.txt" file.
The primary objective that Adobe has in mind when designing this sandbox feature was to prevent a malicious PDF file to drop a file on disk, or to spy on user’s interactions (to counter keylogger-like malicious PDF).
From a technical standpoint, Adobe explains that the "Protected Mode" has been implemented taking the Google Chrome sandbox as model, and uses the sandboxing techniques offered by Microsoft Windows. When launched, Adobe Reader creates a first process: the "Broker". This process configures and starts a second process which is the "sandbox" itself. Any prohibited operation intercepted in the Sandbox (through classical "hooking" mechanisms, see our article of April 2006 which explains the "hooking" principles) is sent from the Sandbox to the Broker (via a shared memory based IPC - Inter Process Communication - mechanism) for inspection. The Broker decides to block or not this suspicious operation according to the defined Policy.
Note: to restrict the privileges of the Sandbox process, Adobe uses several mechanisms available on Windows, one of them is the integrity levels mechanism (a process that is started with a low integrity level can not communicate with processes that run with a higher integrity level). In the case where an attack is able to execute arbitrary code in the sandbox, it would execute this arbitrary code at a low level of integrity which limits the possible harmful actions on the platform. This integrity level mechanism only exists for Windows Vista and later, and is not available on Windows XP. Despite the lack of the integrity level mechanism, the Adobe sandboxing feature is still a significant security improvement for Windows XP users: the primary objective of this sandboxing is to block write attempts and integrity level is just an additional protection mechanism.
2) Is the Adobe Reader Sandbox effective?
According to Adobe (see the last paragraph of this statement dated February 2012), up to now none of the attacks seen in the wild was able to defeat the sandbox protection implemented by Adobe Reader X. Several studies were published in conferences about the security of Adobe Reader X (see the "More information" section at the end of the article). They show the following:
- The classical attacks (that exploits a vulnerability in Reader to install malware on the computer of the victim) are actually defeated by the protection.
- But new attacks, which would be designed taking into account the Adobe "Protected Mode", remain possible.
- The first approach does not try to escape from the sandbox limitations and just performs operation permitted by the sandbox. For example, the sandbox does not prevent network access, read access to the file system and registry, or read and write access to the clipboard. This offers several options for malicious code to run harmful actions in the sandbox.
- The second approach is to attack the Sandbox mechanisms. For example the malicious code may try to attack the Broker by dropping malformed requests in the memory space reserved for IPC communication between the Sandbox and the Broker. It can also try to exploit weaknesses in the engine responsible for enforcing the restriction "policies", in such a way to relax these restrictions. The CVE-2011-1353 vulnerability (Adobe Reader X Sandbox Bypass Vulnerability), corrected in September 2011, allows to exploit such policy engine weaknesses.
3) Other technologies that implement sandboxing
Adobe has first implemented this sandbox technique on Adobe Reader 10 (available since November 2010). It later extended it to Adobe Acrobat 10.1 (available since June 2011). In the case of Acrobat, Adobe has called this feature: "Protected View". When "Protected View" is enabled (it is not the default setting) PDF files are opened in a "Read-only" mode using the same sandbox mechanism as the Adobe Reader "Protected Mode". Once the document has been successfully opened, the user can then exit the "Protected View" and the document is now open in a full, unsandboxed Acrobat process. The following article from Adobe further describes "Protected View" feature: Protected View in Acrobat X, Version 10.1
In the same time, Adobe is also working to add the sandbox feature to its other leading product: Adobe Flash Player. In this case this function is implemented by the web browser (because Flash is a plug that is run into the user's web browser):
- For Internet Explorer, Flash Player is compatible with Internet Explorer "Protected Mode" on Windows Vista and Seven. This provides a protection similar to the Adobe Reader sandbox.
- Flash Player also works sandboxed in Google Chrome since December 2010 (see this announcement on the Adobe blog).
- Flash Player sandboxing on Firefox has been announced in February 2012 (see this announcement on the Adobe blog).
Beyond Adobe solutions, sandboxing technology has also been implemented in several other products. Interested readers will find at the end of this article a pointer to a study of the security of the sandboxes for the following products: Microsoft Internet Explorer, Adobe Reader and Google Chrome.
4) Conclusion
Everyone agrees that the sandbox feature introduced in version 10 of Adobe Reader is a significant advance in security. It is not a panacea and the existing literature suggests that there are still avenues to explore that could result in attacks bypassing this security enhancement. However, it radically changes the threat landscape and, according to Adobe, so far none of the classical PDF attacks (the ones where a trapped PDF file tries to drop a malicious file on the victim’s computer) was able to succeed in environments where the sandbox feature was enabled.
It is worth noting that there are some restrictions to the use of this feature (described in this Adobe note), including: known incompatibilities with some versions of antivirus (McAfee and Symantec), or with software aid for the visually impaired on Windows XP. It is also not available on Linux and Mac OSX.
Finally we recommend to continue to disable JavaScript support in Adobe Reader, even on systems using this sandbox (two precautions being better than one!).
For more information:
Adobe documentation about Adobe Reader X « Protected Mode »:
http://blogs.adobe.com/asset/2010/11/adobe-reader-x-is-here.html
Security studies about Adobe Reader X « Protected Mode »:
- March 2011 – CanSecWest : A Castle Made of Sand: Adobe Reader X Sandbox (SourceFire)
http://cansecwest.com/csw11/A%20Castle%20Made%20of%20Sand%20-%20Johnson.pptx - August 2011 – Blackhat US : Playing in the Reader X Sandbox (IBM X-Force)
http://www.blackhat.com/html/bh-us-11/bh-us-11-archives.html
- Mars 2011 - BlackHat Europe 2011 - Stanislas Quastana report - part 1
(see the section covering the « Escaping from Microsoft Windows Sandboxes» session)
http://blogs.technet.com/b/stanislas/archive/2011/03/22/blackhat-europe-2011-compte-rendu-de-quelques-sessions-partie-1.aspx