BamsBamx
BamsBamx

Reputation: 4256

PendingIntent with FLAG_MUTABLE risk examples?

As stated in the PendingIntent section of the Mitigate security risks in your app in the Android Developer documentation, an application that receives a PendingIntent can modify unfilled fields of a PendingIntent to allow access to otherwise non-exported components of the vulnerable application:

Risk: Mutable Pending Intents

A PendingIntent can be mutable, which means that the inner intent that specifies the action can be updated by application B following the logic described in the fillIn() documentation. In other words, the unfilled fields of a PendingIntent can be modified by a malicious app and allow access to otherwise non-exported components of the vulnerable application.

Because of this risk they created a Lint warning for app sources that use PendingIntents without mutability flag, as posted in this question

Can you show an example or a real use case of how such risk could be exploited?

Code snippets help understanding and are appreciated

Upvotes: 0

Views: 283

Answers (1)

ΓDΛ
ΓDΛ

Reputation: 11100

Sample Code

val updatedPendingIntent = PendingIntent.getActivity(
   context,
   NOTIFICATION_REQUEST_CODE,
   updatedIntent,
   PendingIntent.FLAG_IMMUTABLE or PendingIntent.FLAG_UPDATE_CURRENT 
)

Up until Build.VERSION_CODES.R, PendingIntents are assumed to be mutable by default, unless FLAG_IMMUTABLE is set. Starting with Build.VERSION_CODES.S, it will be required to explicitly specify the mutability of PendingIntents on creation with either (FLAG_IMMUTABLE} or FLAG_MUTABLE. It is strongly recommended to use FLAG_IMMUTABLE when creating a PendingIntent. FLAG_MUTABLE should only be used when some functionality relies on modifying the underlying intent, e.g. any PendingIntent that needs to be used with inline reply or bubbles.

Upvotes: 1

Related Questions