Android M: Security Thoughts from the Keynote

Every release of Android packs-in new features and updates. Android M was recently announced at Google IO conference in San Francisco, CA. During the keynote, several features were discussed, many of which have security and privacy implications. A brief overview of the new features follows.

App Permission System

Google announced a new App permission model, which is a significant change as compared to the existing model. In Android M, users will no longer see the permission approval prompt at the start of the App’s installation process. Instead, an App will ask for the user’s approval at the time it needs the permission to be enabled, allowing the user to grant or deny access based on the feature of the App they may want to use and the App’s context. For example, if an App wishes to access the user’s photo library, the user will no longer see the permission at install time, but at the exact moment the App wants to access the photo library. Users can also revoke any approved permission at a later point in time. This change is significant as the previous permission model was “all or nothing”, and it will impact how Apps receive access to the user’s data by providing a lot more control to the user. Looking at the Android documentation for this change, one interesting comment is that “When the user installs or updates the app, the system grants the App all permission that the App requests that fall under PROTECTION_NORMAL”. Currently, Android does expose some sensitive permissions that are marked as PROTECTION_NORMAL, including:

WRITE_SETTINGS: Allows an App to read or write system settings.
READ_EXTERNAL_STORAGE: Allows an App to read external storage.
GET_ACCOUNTS: Allows an App to access user’s email address. It would be interesting to see how Android M would handle the above normal permissions which allow an App to collect sensitive information from the device.

For readers who are interested in seeing a complete list of all permission with normal protection level navigate here : https://android.googlesource.com/platform/frameworks/base/+/master/core/res/AndroidManifest.xml.

App Linking

Android M introduces a more robust way to handle App linking. Previously, any App could declare an IntentFilter for a specific URL schema *e.g. “myapp://”). Then, whenever a link with this URL schema was triggered directly or indirectly by the user, a “Complete action using” window was displayed to the user with the list of all installed Apps that have declared the ability to handle “myapp://” URLs. See image below as an example:

On Android M, the “Complete action using” window can be entirely skipped. Owners of any web-domain that contains a link to Android App can now declare an association between the web-domain and a particular Android App. When a user clicks this link, the Android App declared in the association will open automatically without prompting the user to select an App from the list. If there are more than one Apps that can handle a link with this particular URL scheme they will be ignored. More on this can be found here: http://developer.android.com/preview/features/app-linking.html

When scanning mobile Apps, we encounter several instances where Apps pass sensitive information via URL Handlers. OAuth access tokens are a good example as when an App performs an OAuth flow on the device’s browser, the only way the OAuth token could be passed to the mobile App is through a URL handler. Now if two Apps define the same URL Handler, both these Apps would be displayed in the “Complete action using” window and there this a chance the user may select the rogue App over the legitimate one. In such scenarios app-linking could prevent the OAuth access token leakage.

Fingerprints and Authentication

Android M will introduce system-level APIs to work with user fingerprints for authentication purposes. While a few Android devices manufacturers already have built fingerprints scanners into the hardware, there previously has not been a standardized way to access scanned fingerprints programmatically and to use them for user authentication (e.g. for unlocking the phone or authorizing a purchase in Play Store). Android M’s fingerprint API will provide a standard way of managing user fingerprints and will allow developers to integrate fingerprint authentication into their apps, assuming the device has hardware capabilities for fingerprints scanning. More on this can be found here: http://developer.android.com/preview/api-overview.html#authentication

HTTPS Only

The following setting in the manifest file <application android:usesCleartextTraffic = "false” /> will now prevent any component in the App from performing network I/O over an unencrypted socket connection. According to the source code, the setting currently supports HTTP, FTP, WebSockets, XMPP, IMAP, SMTP traffic. This is particularly useful when an App has third party libraries that use insecure channels of communication. It should be noted that the flag is not 100% effective, as the source states it is a best effort mechanism and there could be ways to bypass this setting. One example would be to open a direct socket connection via {java.net.Socket}. Reference: Network Security Policy

Now on Tap

The Now on Tap feature will allow users to leverage the Google Now service while running the App itself, without the need to switch between the two apps. Now on Tap will also analyze the current information on the screen at the moment the user calls for it, in order to provide a more accurate answer. For example, when the user receives a text message about dinner plans, they can activate Now on Tap by pressing the Home button, which will display the best suitable dinning places nearby. It is too early to fully understand the privacy implications of analyzing the context and data within third-party Apps, but it appears that any private data could be read by the Now on Tap assistant. One example that comes to mind is medical apps with health information, may be accessed by Now on Tap. The user does have to perform some action to invoke “Now on Tap”, so it might be safe to assume they are okay with sharing such data.

Chrome custom tabs

Android now allows App developers to launch custom Chrome tabs to load web-content. From a security perspective this is slightly better than launching WebViews and loading untrusted third party content on these WebViews. WebViews run as part of App’s process and JavaScript running on WebView may access App’s private storage or any exposed native methods through the JavaScriptInterface. Any, misconfiguration or security issue with the WebView can affect the parent App. On the other hand, Chrome custom tabs provide similar functionality without the problems encountered on WebViews.

AutoBackUps and android:allowBackup=”false”

In Android M, App data will be automatically backed-up onto Google Drive on a daily basis, when the phone is connected to Wi-Fi and power. If the user removes and re-installs the app, or installs the App onto a different Android device with the same Google account, the app’s data will be retrieved from Google drive. The data stored in Google Drive will be automatically encrypted; however, end user’s can opt out of the new feature if they don’t want Google to hold their private information (even if it is encrypted).

Mobile developers can choose to limit the data that is backed-up or simply disable this feature globally by setting android:allowBackup=”false” in the app’s AndroidManifest.xml file. More on this can be found here: http://developer.android.com/preview/backup/index.html

Access to Hardware Identifier

Programmatic access to the Device’s WiFi Mac Address and the Bluetooth Adapter Address have been removed in Android M. Applications can still call WifiInfo.getMacAddress() and BluetoothAdapter.getAddress() however the methods now return a constant value of 02:00:00:00:00:00, hence providing greater data protection to users.