Reputation: 4256
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
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