In recent years, the emergence of publically available fuzzing frameworks has supported a shift in focus from OS vulnerabilities to application vulnerabilities. Vulnerabilities targeted in applications
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
With this focus on application vulnerabilities and the fact that hacking has transformed into an instrument of serious cybercrime, ensuring that security is built into the application from the initial development stages is essential. This is where the application sandbox comes in. Sandboxing is a popular technique for the creation of confined execution environments.
A typical process using sandbox technology can prevent the following actions:
- Launching external processes from within the application
- Writing to the file-system: Enforcement of policy Exceptions like %TEMP%, %APPDATA%\Adobe
- Writing to registry: Enforcing policy exceptions like HKCU\Software\Adobe\Acrobat Reader\
- Shatter attacks: Sending Windows messages or installing Windows hooks to other processes can be prevented using a separate sandbox
- Modifying objects of other processes
- Unauthorized reads or network access (a mitigation that the current Reader sandboxed implementation does not provide)
The premise of sandboxing is that even if an arbitrary code execution exploit is affected by an attacker, the constrained environment restricts the damage caused by confining exploit code to the sandbox. A sandbox limits access levels of the applications within — it is a container. Sandbox processes cannot write to disk or ideally display their own windows. Their abilities are controlled by explicit policies.
We will primarily focus on Windows application sandboxes that can be used during application development to build in this kind of threat mitigation. This tutorial intends to explain “sandboxing” as a technique for threat mitigation taking the example of Adobe Reader.
Adobe reader uses a technology based on Microsoft’s Practical Windows Sandboxing technique. Functionality beyond the restrictions posed by sandboxing is achieved through separate trusted processes that run concurrently with the sandboxed process.
The variety of environments that sandboxes are deployed on is a major challenge. For example, in the case of a typical Windows application supported on Windows XP, Windows Vista and Windows 7, a sandboxed design that operates seamlessly across all these platforms is a hard nut to crack.
Another challenge during implementation of sandbox architecture for an application with the help of the trusted process is to keep a small codebase for the broker process. This does not open too many holes that may form attack vectors.
Lastly, bringing sandboxing to a mature application with a legacy codebase containing millions of lines of code and several user workflows is not as simple as adding a secure wrapper. The restrictions posed by a sandbox environment make it a challenge to maximizing an application’s functionality.
For our example, Adobe Reader X needed to support the following functionality:
- Third-party plug-ins that face issues when loaded in the sandbox
- Accessibility tools like screen readers that access out-of-proc COM objects
- Input method editor (IME) that needs access to keyboard layouts and SendMessage to IME windows
- Smartcards with too many diverse drivers to get all working
- Antivirus solutions that perform their own interceptions which may conflict with the sandbox’s design
Figure 1: File Access form a Sandbox
How does ‘protected mode’ work?
Keeping these requirements in mind, a sandbox environment must adhere to the principle of least privilege. This requires that in a particular abstraction layer of a computing environment, every module must only have access and execution rights that are necessary for its legitimate functioning. The Windows platform provides a number of security mechanisms to create a sandboxed application. Sandboxing for Adobe Reader’s ‘protected mode’ was achieved by imposing restrictions on the Reader process, as explained in the following slides.
The basic components of Adobe Reader's sandbox mechanism are:
- Restricted user access tokens
- Restricted job objects
- Windows integrity mechanism (Integrity Levels; Windows Vista and higher) and desktop isolation
- Two process architecture
This tutorial is based on inputs from Disha Agrawal and Manish Pali’s talk at nullcon 2012, held at Goa in February 2012.
About the author: Disha Agarwal is a Senior Software Engineer at Adobe Systems. She is part of Adobe's security engineering team working on the Adobe Reader sandboxing project, and has been involved with the project since its inception. She takes keen interest in secure software development, penetration testing, fuzzing, exploit writing and analysis.
|(As told to Varun Haran)||Follow @SearchSecIN|
This was first published in March 2012