Android adds a Secure Default for Content Providers

Security requires some thought in design, lots of developer attention in secure coding, but there are gaps that the platform can close that can make the designer and the developers lives easier, setting secure defaults. Default Android introduces a number of ways that companies can unwittingly open up vulnerabilities. Jelly Bean offers a number of security improvements, one of the more interesting is adding a new and important Secure Default which protects Content Providers, aka your data. The setting protects against data inadvertently leaked to other apps. Android's permission model is pretty expressive and lets you set fine grained access control policy. Unfortunately, this means that there are many options and so many enterprises that ship with default settings can expose their data to any other app running on the Android device.

Most developers assume that when they create a database for their Android application that its only able to be used by their app. Unfortunately, this assumption is not valid. The security policy defined in the Android Manifest is the place to check to make sure this is set properly. A developer who sees the following may assume their data is protected:

<provider android:name=”com.example.ReadOnlyDataContentProvider”

    android:authorities=”com.example” />

But for Android 4.1 or prior the Manifest has an insecure default for Content Providers in that if read and write permission are not set (turned off) then its assumed that your Content Provider is readable and writeable by other apps. (note - its unlikely but I can imagine why some app might want their data readable by other apps, why there is a default for other apps to write is something I have never understood). In any case, if you have deployed Android apps its pretty likely that you have the defaults set unless someone specifically turned off read and write acces, so you should check the Android security policy and test the app.

How to check
For yours apps, the best place to start is to review your Android Manifest.xml and check that the permissions are set to disallow access that you do not want, such as other apps reading and writing to your apps databases. On 4.1 or prior this has to be set otherwise the permission is granted.

How to test
There are a variety of ways to test for this, the Mercury test suite for Android gives you a way to see what is running:

               ..                    ..:.
              ..I..                  .I..
               ..I.    . . .... .  ..I=
                 .I...I?IIIIIIIII~..II
                 .?I?IIIIIIIIIIIIIIII..
              .,IIIIIIIIIIIIIIIIIIIIIII+.
           ...IIIIIIIIIIIIIIIIIIIIIIIIIII:.
           .IIIIIIIIIIIIIIIIIIIIIIIIIIIIIII..
         ..IIIIII,..,IIIIIIIIIIIII,..,IIIIII.
         .?IIIIIII..IIIIIIIIIIIIIII..IIIIIIII.
         ,IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII.
        .IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII.
        .IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII:
        .IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

        The heavy metal that poisoned the droid
     
mercury> connect 127.0.0.1

*mercury> provider

*mercury#provider> info -p null

Package name: com.example.myapp
Authority: com.example.myapp.mydataprovider
Required Permission - Read: null
Required Permission - Write: null
Grant Uri Permissions: false
Multiprocess allowed: false

Package name: com.android.alarmclock
Authority: com.android.alarmclock
Required Permission - Read: null
Required Permission - Write: null
Grant Uri Permissions: false
Multiprocess allowed: false

Package name: com.android.mms
Authority: com.android.mms.SuggestionsProvider
Required Permission - Read: android.permission.READ_SMS
Required Permission - Write: null
Path Permission - Read: /search_suggest_query needs android.permission.GLOBAL_SEARCH
Path Permission - Read: /search_suggest_shortcut needs android.permission.GLOBAL_SEARCH
Grant Uri Permissions: false
Multiprocess allowed: false

(truncated)

Probably most Android apps have null permissions set and do not realize that it is the case or the impact of that omission (that other apps can read and write their data). In the case above the example app is set to allow other applications read and write its data. This happens many times with Android apps that contain sensitive data and the companies do not realize the exposure. This is just a snapshot but the Android permission sets are very much like a Purdy shotgun, great for skilled hunters, but also great for committing suicide.

**
Three days of iOS and Android AppSec geekery with Gunnar Peterson and Ken van Wyk - Training dates NYC April 29-May 1