Author Archive: ddefigue

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"
                    package="com.adobe.reader">
   <application label="Adobe Reader" icon="res/drawable-hdpi/icon.png"
                    debuggable="true">
      <activity theme="@16973830" label="Adobe Reader" name=".AdobeReader"
                    launchMode="2" screenOrientation="2" configChanges="0xa0">
         <intent-filter>
            <action name="android.intent.action.MAIN">
            </action>
            <category name="android.intent.category.LAUNCHER">
            </category>
         </intent-filter>
         <intent-filter>
            <action name="android.intent.action.VIEW">
            </action>
            <category name="android.intent.category.DEFAULT">
            </category>
            <data mimeType="application/pdf">
            </data>
         </intent-filter>
      </activity>
      <activity theme="@2131034112" name=".ARAboutActivity">
      </activity>
      <activity theme="@16973830" name=".ARFileOpen" configChanges="0xa0">
      </activity>
      <activity theme="@16973830" name=".ARPortfolioUI">
      </activity>
   </application>
   <uses-sdk minSdkVersion="7">
   </uses-sdk>
</manifest>

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.

Now’s the time to ask

If you have a burning product security question you want to ask Adobe, don’t miss this chance! Adobe’s Brad Arkin is taking part in a live chat session on Threatpost tomorrow (Feb. 24) at 1:30pm ET. Have your questions ready!
arkin_unit_4.jpg

Brad’s BigFix Interview

The first part of Brad Arkin’s multi-part podcast interview with BigFix CTO Amrit Williams is now available. In his role as director of security and privacy, Brad guides Adobe’s long term security strategy. Part 1 of the interview describes Adobe’s current security focus and outreach efforts. It is a quick 9 minutes, check it out.
UPDATE: Part 2 and Part 3 are now available and complete the series. Part 2 touches on defense strategies and the internals of the PSIRT process, whereas Part 3 focuses on security during the product development cycle.

Brad’s Reality Check Interview

Our own Director of Product Security and Privacy, Brad Arkin, was recently interviewed by Gary McGraw in Cigital’s Reality Check Podcast series. From our Secure Product Livecycle to training and certification, the conversation touches on various aspects of software security and provides an overview of ASSET’s strategies to continuously enhance the security of Adobe’s products. Check it out!

Adobe Sponsors ShmooCon 2009

Hello All! This is Dimitri writing here. I am happy to say that Adobe is sponsoring ShmooCon 2009 as part of our security community outreach efforts. We want to help the security community exchange ideas and develop secure software practices.
Senior Security Researcher Peleus Uhley and I will be roaming the conference floors and would be most interested in talking to other security researchers about the security of Adobe products. So, if you will be in Washington D.C. attending the conference at the end of this week, come say hi! I don’t bite and neither does Peleus!

Welcome!

The Adobe Secure Software Engineering Team (ASSET) is pleased to announce this new blog!
Since we care about the security and privacy of our products and we want to share our company knowledge and efforts with the security community, we are starting up this new blog. Topics may range from Adobe’s experience implementing a secure product lifecycle to new security initiatives in our products. We will most likely not dive deep into individual Adobe products here, but instead focus on more general issues. If you are interested in what Adobe is doing to improve the security of its products, read on.
For the latest information on security bulletins or advisories, please go to our PSIRT blog.