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.