These aren't the apps you're looking for [Move along] [Part I]

I do research with Prof. Dave Naumann about the security of information flow in Android. Without going into too much detail, here's a brief explanation of why we'd look at it and how it could be abused.

When you download an app, usually it lists a certain set of permissions - it wants to access the internet so that it can communicate with its servers, it wants your GPS information so that it can tell you how to get to your destination, or it wants the ability to send text messages so it can make them look pretty on your friend's phone. Now, these permissions are sort of a "disclaimer" - they're telling the user, "As an app on your phone, you are allowing me to access the internet in whatever way I see fit." Now, if a developer does not declare that he wants permission to use the internet, the app [ideally] is prevented from using any piece of the Android API pertaining to the internet.

Unfortunately, the Android system is not airtight - by design, most likely. Apps can interact with one another, and here lies one of the more vulnerable features of Android. Consider the following system of apps: 

Developer John creates two apps, A and B, and publishes both.

App A - has permission to send text messages, and is designed to let you send pre-written messages to your friends (so you can set up an away message when you're on vacation or something).

App B - has permission to access your contacts, and improves on the way that Android displays contacts, to make it easier for the user to read and search.

John is a malicious developer, however, and makes his apps interact with each other. App B can get your contact information, store it in a place that app A can access [allowable since they are developed by the same person], and then app A can get that information and send it in a text message to Developer John's phone, which then stores it in a database, releases it to the NSA, posts it on public bulletin boards, and other generically evil things.

This is a feature of the Android API - they meant to allow apps designed by the same developer communicate with each other, in order to store user preferences more easily. In short, Android won't fix these security leaks, because they're part of the intended design. Instead, a per-app analysis is needed to ensure that the given app does not leak information to places not explicitly stated in a developer-defined policy of the app. The difficulty in this is that even if you can check all of a person's code, it is difficult to determine whether a piece of information stored in a database on your phone is intended to be secret or not. Professor Naumann is working on implementing an analysis tool that would run [most likely] on an entire phone, checking that the entire phone is secure, apps included. Of course, it would be better to have it run on a per-app basis, but because of the general structure of the android system, it may not be feasible to have it correctly check an app without having checked the previously installed apps first.

I recently started reading [but have not yet finished] reading a research paper that was describing ways of releasing private information from one app to another, and eventually to the internet, without the use of ANY permissions. These channels of information leaks seem to be more based on the underlying Linux system rather than on the Android API itself, but when I finish reading this paper I will post a Part II about how those channels work and what the workaround might be [if any].