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
android:priority value in the
If you read
the documentation for
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
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”.
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
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.