The CommonsBlog

The Troubling Tale of android:priority

About six weeks ago, I warned about the possibility of man-in-the-middle (MITM) attacks on exported services. In there, I wrote:

…what happens if there are two (or more) services installed on the device that claim to support the same <intent-filter>, but have different package names? You might think that this would fail on install, as happens with providers with duplicate authorities. Alas, it does not. Instead the first one in “wins”.

The last bit, about installation order, is true… assuming that both services have the same android:priority value in the <intent-filter>.

If you read the documentation for android:priority, you will notice that it only covers activities and ordered broadcasts. Worse, the activities documentation seems to be in error – AFAICT, only a system app can take precedence over other apps’ activities using android:priority. Ordered broadcasts are where most Android developers encounter android:priority.

The documentation does not mention services. Silly me thought that android:priority played no role with services.

The key word in that previous sentence was “silly”.

Dominik Schürmann’s work on uncovering the bugs in Google Play’s in-app billing pointed out that android:priority does play a role with services. If two or more services are installed, each exporting the same basic <intent-filter> structure (e.g., same <action>), the one with the highest android:priority will silently take precedence. Only if there is a tie – such as with no android:priority at all – will installation order determine which one “wins”.

This makes the MITM attack that much easier to execute, as installation order no longer matters quite so much.

As I wrote previously, if you want to make sure that you are talking to the right third-party app, by any IPC mechanism, you will need to compare the public keys. The public key that signed an app is part of the APK; only apps signed by the same private key should contain the same public key. I will point you to that previous blog post for some discussion of how to check the public key. Note that this material is also covered in the current update of my book, and I will be augmenting that coverage to mention the android:priority aspect of the problem in the next book update.

Need an Android programming guide for your development team? An Enterprise Warescription to The Busy Coder’s Guide to Android Development is available for teams of 10+ members. Contact Mark Murphy for details.