Posts tagged "sandbox"

Flash Player Sandbox Now Available for Safari on Mac OS X

Posted on October 23, 2013 by | Comments (0)

Over the last few years, Adobe has protected our Flash Player customers through a technique known as sandboxing. Thus far, we have worked with Google, Microsoft and Mozilla on deploying sandboxes for their respective browsers. Most recently, we have worked with Apple to protect Safari users on OS X. With this week’s release of Safari in OS X Mavericks, Flash Player will now be protected by an OS X App Sandbox.

For the technically minded, this means that there is a specific com.macromedia.Flash Player.plugin.sb file defining the security permissions for Flash Player when it runs within the sandboxed plugin process. As you might expect, Flash Player’s capabilities to read and write files will be limited to only those locations it needs to function properly. The sandbox also limits Flash Player’s local connections to device resources and inter-process communication (IPC) channels. Finally, the sandbox limits Flash Player’s networking privileges to prevent unnecessary connection capabilities.

Safari users on OS X Mavericks can view Flash Player content while benefiting from these added security protections. We’d like to thank the Apple security team for working with us to deliver this solution.

Peleus Uhley
Platform Security Strategist

Reader 9.x Reaches End-of-Life

Posted on June 26, 2013 by | Comments (0)

In line with the Adobe Support Lifecycle Policy, Adobe’s Acrobat 9.x and Reader 9.x suite of products reached their end-of-life (EOL) today, June 26, 2013. This means that Adobe will no longer provide security or other updates to this product suite.

Over the years, we’ve made several security enhancements in the successors of Reader 9, Reader X and Reader XI, including the Protected Mode (aka “sandboxing”) and Protected View. There has never been a better time to upgrade to Reader XI. Please upgrade, ensure automatic updates are turned on, and stay secure!

Karthik Raman

Security Researcher, ASSET

New Security Capabilities in Adobe Reader and Acrobat XI Now Available!

Posted on October 17, 2012 by | Comments (0)

This week, Adobe released the next generation of Adobe Reader XI and Acrobat XI with improved security features, among many other enhancements.

Adobe Reader X represented a milestone release in terms of security with the introduction of Adobe Reader Protected Mode (aka “sandboxing”), which created a more secure environment for our customers. We followed the Adobe Reader X release with the introduction of Adobe Acrobat X (10.1) Protected View. Since we added sandbox protection to Adobe Reader and Acrobat, we have not seen any exploits in the wild that break out of the Adobe Reader and Acrobat X sandbox.

Over the last year, we have continued to work on adding security capabilities to Adobe Reader and Acrobat, and today, we are very excited to present Adobe Reader and Acrobat XI with a number of new or enhanced security features.

Adobe Reader XI Protected Mode (Enhanced)

In our Adobe Reader X sandbox implementation, the sandboxing architecture’s primary focus was on “write protection” to prevent the attacker from installing malware on the user’s machine and from monitoring the user’s keystrokes when the user interacts with another program.

In Adobe Reader XI, we have added data theft prevention capabilities by extending the sandbox to restrict read-only activities to help protect against attackers seeking to read sensitive information on the user’s computer.

Adobe Reader Protected View (New) and Adobe Acrobat Protected View (Enhanced)

To provide an additional layer of defense and strengthen the sandbox protection in Adobe Reader and Acrobat even further, we have implemented a separate desktop and WinStation in Adobe Reader and Acrobat XI, which will block, for instance, screen scraping attacks. For additional insights into implementing a separate desktop to provide an additional layer of defense, see David LeBlanc’s Web log entry Practical Windows Sandboxing – Part 3. For details on WinStations and desktops in general, click here.

This mode effectively introduces a new Protected View in Adobe Reader and enhances the Protected View implementation in Adobe Acrobat even further. Protected View behaves identically for Adobe Reader and Acrobat, whether viewing PDF files in the standalone product or in the browser. For more information, administrators can refer to the Enterprise Toolkit for Acrobat Users.

Force ASLR Support in Adobe Reader/Acrobat XI

Adobe Reader and Acrobat leverage platform mitigations such as Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR), etc. In Adobe Reader and Acrobat XI, we have enabled support for Force ASLR on Windows 7 and Windows 8. Force ASLR improves the effectiveness of existing ASLR implementations by ensuring that all DLLs loaded by Adobe Reader or Acrobat XI, including legacy DLLs without ASLR enabled, are randomized. By enabling Force ASLR in Adobe Reader and Acrobat XI, we are making it even more difficult for an attacker to exploit vulnerabilities. For more information on ASLR and Force ASLR, please refer to Microsoft’s Knowledge Base article on the topic.

PDF Whitelisting Framework

For high-assurance, managed enterprise environments, we’ve added the Adobe PDF Whitelisting Framework, which allows administrators to selectively enable advanced functionality, such as JavaScript for specific PDF files, sites or hosts, on both Windows and Mac OS.

Support for Elliptic Curve Cryptography

And last but not least, we have added support for Elliptic Curve Cryptography (ECC) for digital signatures in the area of content security. Users can now embed long-term validation information automatically when using certificate signatures and use certificate signatures that support elliptic curve cryptography (ECC)-based credentials.

We’re excited about these additional security capabilities in Adobe Reader and Acrobat XI, which mark the latest in our continued endeavor to help protect our customers by providing a safer working environment.

Priyank Choudhury
Security Researcher, Adobe Secure Software Engineering Team (ASSET)

Inside Flash Player Protected Mode for Firefox

Posted on June 7, 2012 by | Comments (0)

Today, we launched Flash Player Protected Mode for Firefox on Windows. Our Protected Mode implementation allows Flash Player to run as a low integrity process with several additional restrictions that prohibit the runtime from accessing sensitive resources. This approach is based on David LeBlanc’s Practical Windows Sandbox design and builds upon what Adobe created for the Adobe Reader X sandbox. By running the Flash Player as a restricted process, Adobe is making it more difficult for an attacker to turn a simple bug into a working exploit. This blog post will provide an overview of the technical implementation of the design.

When you first navigate to a page with Flash (SWF) content, you will notice that there are now three processes for Flash Player. This may seem odd at first, but there is a good reason for this approach. One of the goals for the design was to minimize the number of changes that were necessary in Firefox to support the sandbox. By keeping Flash Player and Firefox loosely coupled, both organizations can make changes to their respective code without the complexity of coordinating releases.

The first process under the Firefox instance is called “plugin-container.exe.” Firefox has run plugins in this separate process for quite some time, and we did not want to re-architect that implementation. With this design, the plugin container itself is only a thin shim that allows us to proxy NPAPI requests to the browser. We also use this process as our launching point for creating the broker process. Forking the broker as a separate process allows us to be independent of the browser and gives us the freedom to restrict the broker process in the future. From the broker process, we will launch the fully sandboxed process. The sandboxed process has significant restrictions applied to it. It is within the sandbox process that the Flash Player engine consumes and renders Web content.

The restrictions we apply to this sandboxed process come from the Windows OS. Windows Vista and Windows 7 provide the tools necessary to properly sandbox a process. For the Adobe Reader and Acrobat sandbox implementation introduced in 2010, Adobe spent significant engineering effort trying to approximate those same controls on Windows XP. Today, with Windows 8 just around the corner and Windows XP usage rapidly decreasing, it did not make sense for the Flash Player team to make that same engineering investment for Windows XP. Therefore, we’ve focused on making Protected Mode for Firefox available on Windows Vista and later.

For those operating systems, we take advantage of three major classes of controls:

The first control is that we run the sandboxed process at low integrity. By default, processes started by the user are executed at medium integrity. Running the process at a low integrity level prevents the process from writing to most areas of the user’s local profile and the registry which require a medium integrity level to access. This also allows us to take advantage of User Interface Privilege Isolation (UIPI) which prevents low integrity processes from sending windows messages to higher integrity processes.

The second class of controls applied to the sandboxed process is to restrict the capabilities of the access token. A process will inherit a list of available Security Identifiers (SIDs) from the user’s security profile. These SIDs represent the different OS groups to which the user belongs. The access token contains this list of SIDs along with a set of controls for those SIDs. The Windows OS will compare the SIDs in the access tokens to the group permissions of the target object (e.g a file) to determine if access is allowed. The Windows OS allows us to define how the process SIDs are used in that comparison.

In general, a sandboxed process will need to be able to access resources directly owned by the user. However, in most cases it is unlikely that the sandbox will need the extended set of resources available to the user via group permissions. As a concrete example, your company may have a contact list on a network share that is available to everyone within your “Employees” group. It isn’t your file but you can access it because you are in the “Employees” group for your company. The Flash Player sandbox process doesn’t need to be able to directly access that file.

We identified that our sandbox process will need to access OS resources using the following SIDs: BUILTIN\Users, Everyone, the User’s Logon SID, and NTAUTHORITY\INTERACTIVE. For any other SIDs that are inherited from the user, we set the deny-only attribute to prohibit the process from accessing the resource based solely on that SID. To continue the example of the contact list on the file share, the sandboxed process would not be able to access the contact list because the file is not owned by you and the deny-only attribute on the “Employees” group SID would prevent access using your group permission. Process privileges are also limited to only the SeChangeNotifyPrivilege, which is required for the process to be notified of file system changes and for certain APIs to work correctly. The graphic below shows the permissions applied to the sandboxed process.

The third control applied to the sandboxed process are job restrictions. As one example, we can prevent the sandboxed process from launching other processes by setting Active Processes to 1. We can also limit the sandbox’s ability to communicate with other processes by restricting access to USER Handles and Administrator Access. The USER Handles restriction complements UIPI by preventing the process from accessing user handles created by processes not associated with our job. Finally, we can limit the sandboxes ability to interfere with the OS by limiting access to System Parameters, Display Settings, Exit Windows and Desktop.

More information on job limits, privilege restrictions and UIPI can be found in Part 2 of Inside Adobe Reader Protected Mode.

Once you get past OS-provided controls, the next layer of defense is Flash Player broker controls.

The OS broker process runs at medium integrity and acts as a gatekeeper between the untrusted sandbox process and the operating system. The sandbox process must ask the OS broker process for access to sensitive resources that it may legitimately need. Some examples of resources that are managed by the broker include file system access, camera access, print access and clipboard access. For each resource request, the sandbox contains policies which define what can and cannot be accessed. For instance, the sandbox process can request file system access through the broker. However, the policy within the broker will limit access to the file system so that the sandbox can only write to a predetermined, specific set of file system paths. This prevents the sandbox from writing to arbitrary locations on the file system. As another example, the sandbox cannot launch applications directly. If Flash Player needs to launch the native control panel, the Flash Player engine must forward the request to the broker process. The broker will then handle the details of safely launching the native control panel. Access to other OS resources such as the camera are similarly controlled by the broker. This architecture ensures that the sandboxed process cannot directly access most parts of the operating system without that access first being verified by the broker.

Overall, the Flash Player sandbox process has been a journey of incremental improvements with each step bringing end-users a more secure environment. We started by supporting Protected Mode within Internet Explorer, which enabled Flash Player to run as a low integrity process with limited write capabilities. From there, we worked with Google on building the Chrome sandbox, which converted Flash Player to using a more robust broker implementation. This release of Flash Player Protected Mode for Firefox on Windows takes the Chrome implementation one step further by changing Flash Player to run with job limits on the process. With Flash Player Protected Mode being based on the same technology as Adobe Reader X, we are confident that this implementation will be a significant barrier and help prevent exploits via Flash Player for Firefox users. Going forward, we plan to continue to build on this infrastructure with more sandbox projects, such as our upcoming release of Flash Player for Chrome Pepper. As we combine these efforts with other efforts, such as the background updater, we are making it increasingly more difficult for Flash Player to be targeted for malicious purposes.

Peleus Uhley, Platform Security Strategist, ASSET
Rajesh Gwalani, Security Engineering Manager, Flash Runtime

Flash Player 11.3 delivers additional security capabilities for Mac and Firefox users

Posted on June 7, 2012 by | Comments (0)

Today’s release of Flash Player 11.3 brings three important security improvements:

  • Flash Player Protected Mode (“sandboxing”) is now available for Firefox users on Windows.
  • For Mac users, this release will include the background updater for Mac OS X.
  • This release and all future Flash Player releases for Mac OS X will be signed with an Apple Developer ID, so that Flash Player can work with the new Gatekeeper technology for Mac OS X Mountain Lion (10.8).

Flash Player 11.3 brings the first production release of Flash Player Protected Mode for Firefox on Windows, which we first announced in February. This sandboxing technology is based on the same approach that is used within the Adobe Reader X Protected Mode sandbox. Flash Player Protected Mode for Firefox is another step in our efforts to raise the cost for attackers seeking to leverage a Flash Player bug in a working exploit that harms end-users. This approach has been very successful in protecting Adobe Reader X users, and we hope Flash Player Protected Mode will provide the same level of protection for Firefox users. For those interested in a more technical description of the sandbox, please see the blog post titled Inside Flash Player Protected Mode for Firefox authored by ASSET and the Flash Player team.

The background updater being delivered for Mac OS X uses the same design as the Flash Player updater on Windows. If the user chooses to accept background updates, then the Mac Launch Daemon will launch the background updater every hour to check for updates until it receives a response from the Adobe server. If the server responds that no update is available, the system will begin checking again 24 hours later. If a background update is available, the background updater can download and install the update without interrupting the end-user’s session with a prompt.

With Mac OS X Mountain Lion (10.8), Apple introduced a feature called “Gatekeeper,” which can help end-users distinguish trusted applications from potentially dangerous applications. Gatekeeper checks a developer’s unique Apple Developer ID to verify that an application is not known malware and that it hasn’t been tampered with. Starting with Flash Player 11.3, Adobe has started signing releases for Mac OS X using an Apple Developer ID certificate. Therefore, if the Gatekeeper setting is set to “Mac App Store and identified developers,” end-users will be able to install Flash Player without being blocked by Gatekeeper. If Gatekeeper blocks the installation of Flash Player with this setting, the end-user may have been subject to a phishing attack. That said, a reminder that Flash Player should only be downloaded from the www.adobe.com website.

Flash Player Sandboxing is Coming to Firefox

Posted on February 6, 2012 by | Comments (0)

Peleus here. In December of 2010, I wrote a blog post describing the first steps towards sandboxing Flash Player within Google Chrome. In the blog, I stated that the Flash Player team would explore bringing sandboxing technology to other browsers. We then spent 2011 buried deep within Adobe laying the groundwork for several new security innovations.

Today, Adobe has launched a public beta of our new Flash Player sandbox (aka “Protected Mode”) for the Firefox browser. The design of this sandbox is similar to what Adobe delivered with Adobe Reader X Protected Mode and follows the same Practical Windows Sandboxing approach. Like the Adobe Reader X sandbox, Flash Player will establish a low integrity, highly restricted process that must communicate through a broker to limit its privileged activities. The sandboxed process is restricted with the same job limits and privilege restrictions as the Adobe Reader Protected Mode implementation. Adobe Flash Player Protected Mode for Firefox 4.0 or later will be supported on both Windows Vista and Windows 7. We would like to thank the Mozilla team for assisting us with some of the more challenging browser integration bugs. For Flash Player, this is the next evolutionary step in protecting our customers.

Sandboxing technology has proven very effective in protecting users by increasing the cost and complexity of authoring effective exploits. For example, since its launch in November 2010, we have not seen a single successful exploit in the wild against Adobe Reader X. We hope to see similar results with the Flash Player sandbox for Firefox once the final version is released later this year. In the meantime, please help us get these protections out to end-users as fast as possible by volunteering to download our beta and help test. Information on known bugs, configuration options and other information can be found on Adobe Labs in the “Getting Started” section.

P.S.: I will be speaking at CanSecWest on this and other exciting topics. I hope to see everyone there!

Inside Adobe Reader Protected Mode – Part 1 – Design

Posted on October 5, 2010 by | Comments (0)

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?

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:

  • 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