Archive for December, 2010

Leveraging the Android Sandbox with Adobe Reader

Hi, Dimitri here. Now that the new Adobe Reader X sandbox has shipped, we are often asked about Adobe Reader for Android. Protecting our phones is increasingly important as more users are relying on them to access sensitive information, such as financial data, location tracking and email. Our use of mobile phones is different from our use of laptops, and there are more security threats to consider with these devices.

The Android Security Model

From a security point of view, the Android operating system is a multi-user Linux system where each application is a different user. This implies that any Linux 2.6 kernel bug that allows a local attacker to gain root privileges is also a potential Android vulnerability. While Android relies on Linux kernel security to achieve isolation between applications, it also provides some extra communication mechanisms of its own that allow different applications to talk to each other. These mechanisms give the operating system and each application fine-grained control over how they can interact.

There are many advantages to isolating different applications. One important benefit is that different applications cannot interfere with each other, unless the communication is mutually consensual. It also means that the principle of least privilege is applied by default, which makes the system more secure.

An Android application needs to be granted permission to access the user’s contact list, to read GPS location data, to access the network, and to do many other things. By default, it does not have permission to do any of this. If an application needs permissions to work, it must ask for those permissions at install time by listing them in its AndroidManifest.xml file. Also at installation time, the Android system will ask the user whether the application should be given the requested permissions. If permissions are granted, Android enforces compliance from then on.

Adobe Reader for Android

I hope you read the previous blog posts about the excellent work the Adobe Reader team has done to implement a sandbox in Adobe Reader X on Windows. With sandboxing, even if an attacker takes over an application’s process, he cannot cause severe harm to the user unless he also manages to break out of the sandbox.

In a sense, Android has sandboxing built-in. Every application in the Android system can be automatically sandboxed. This is great for the system’s security! Adobe has taken full advantage of this feature with Adobe Reader X. Here is the AndroidManifest.xml file for Adobe Reader:

<manifest versionCode="35282" versionName="10.0.0" installLocation="0"
   <application label="Adobe Reader" icon="res/drawable-hdpi/icon.png"
      <activity theme="@16973830" label="Adobe Reader" name=".AdobeReader"
                    launchMode="2" screenOrientation="2" configChanges="0xa0">
            <action name="android.intent.action.MAIN">
            <category name="android.intent.category.LAUNCHER">
            <action name="android.intent.action.VIEW">
            <category name="android.intent.category.DEFAULT">
            <data mimeType="application/pdf">
      <activity theme="@2131034112" name=".ARAboutActivity">
      <activity theme="@16973830" name=".ARFileOpen" configChanges="0xa0">
      <activity theme="@16973830" name=".ARPortfolioUI">
   <uses-sdk minSdkVersion="7">

The most important thing to notice is what is missing from this file. Adobe Reader does not ask for any permissions. As it turns out, we currently do not need to ask for any extra permissions to render documents. This means that Adobe Reader on Android already comes in a nice and strict sandbox.

If an attacker creates a malicious PDF file and is able to take over the Adobe Reader application running on your phone, he can run down your battery. He may also be able to use up all system resources or to brick your phone by sending multiple messages to the screen. He cannot, however, read your contact list, obtain your GPS location data, turn your camera on or even access the network! Unless there is a security bug in Android, all the attacker can do is perform a Denial-of-Service attack on your phone, which is undoubtedly extremely inconvenient, but not as costly as losing control of your personal information.

This fine-grained permissions-based sandbox-ready security model is currently only available on Android. Reader mobile users that have an Android phone should know that, even though this is not our first line of defense, Adobe Reader makes full use of Android’s application sandbox.

The Year of the Sandbox isn’t Over Yet!

Peleus here. It may be December, but we still have time to squeeze one more sandbox into what some security people have referred to as “the year of the sandbox.” We recently posted a number of blogs describing the design and testing that went into the Adobe Reader X sandbox. So, what about Adobe Flash Player? Flash Player already supports Protected Mode in Internet Explorer on Windows 7 and Windows Vista, which helps run Internet Explorer and Flash Player in a low integrity process. However, this only helps a subset of Windows users.

To further extend our sandboxing efforts, Adobe has been working with Carlos Pizano and the Google Chrome team on a prototype sandbox for Flash Player within the Chrome browser. Today, the Chrome team published a brief introduction to the effort on the Google Chrome blog. The associated Chrome and Flash Player builds have been published on the Chrome developer and canary channels.

We have enabled sandboxing support within Chrome’s integrated version of Flash Player (gcswf32.dll). For initial testing, the sandboxing code currently supports Windows XP, Windows Vista and Windows 7. There are plans to make this available for all OS platforms once we are further along in testing and development. For Windows operating systems that support UAC, the sandbox allows Flash Player to run as a low integrity process.

Over the next few months, we will be testing and receiving feedback on this project. Since this is a distinctly different sandboxing code base from Internet Explorer, we are essentially starting from scratch. Therefore, we still have a few bugs that we are working through. We hope that we can use this experience as a platform for discussing sandbox approaches with the other browser vendors.

The Flash Player team and the Adobe Secure Software Engineering Team (ASSET) are excited to explore this area as an additional defense for protecting our end-users. In addition to sandboxes, we are moving forward in parallel with other Flash Player defenses, such as JIT spraying mitigations. I plan to discuss some of those features in a future blog post. In the meantime, please check out the Google Chrome blog, and if you are a Chrome user, please help us test this new approach.! Thanks to Carlos Pizano and the Google Chrome team for all their assistance in helping drive this project!