Exploiting AIDL and Parcelable Mismatches in Android IPC

Previous Summary

Earlier we introduced how custom read/write methods in various Parcelable implementations can cause data corruption, leading to scenarios where validation at point A succeeds but the data received at point B becomes invalid.

We have already covered three classic cases:

Classic mismatch where read and write use different primitive types, causing altered values on second read.

Exception handling that returns null on read, causing premature termination and data changes on subsequent reads.

LazyValue retaining a Parcel pointer after parsing, leading to use‑after‑free when the Parcel is recycled.

This article adds two more cases.

AIDL and Subclasses

Android Interface Definition Language (AIDL) abstracts inter‑process communication. The .aidl file defines an interface, and build systems generate C++ or Java bindings using the aidl compiler, which produces the underlying Binder transact code.

Implementing the generated interface yields code similar to the following:

The onTransact methods are auto‑generated and not visible in source, but decompilation reveals the generated code handling Parcel read/write for both the Stub and Proxy.

When a Parcelable subclass is used, the generated code calls the appropriate read/write methods. However, if the write side calls a different implementation (e.g., a subclass of Intent), mismatches can occur.

Type Restrictions

1. Specified‑type Interfaces

All Parcelable‑related vulnerabilities share a simple root cause: mismatched read/write logic. Google has attempted to mitigate these issues by moving away from type‑agnostic interfaces toward ones that enforce explicit class types, reducing the chance of arbitrary class instantiation.

Nevertheless, the original exploitation point—using a mismatched Parcelable—remains viable because the system still invokes createFromParcel for any Parcelable, even without a type check.

2. Other Problematic Parcelables

Some Parcelables perform unrestricted reflection on classes that accept a single Parcel in their constructor, enabling arbitrary code execution. For example, Samsung's com.samsung.android.content.clipboard.data.SemImageClipData logs exceptions without further handling, allowing it to be used in exploit chains.

By crafting a Parcelable array that triggers createFromParcel on each element, an attacker can force a class cast exception after the method returns, potentially bypassing normal checks.

Summary

Two additional Parcel‑related issues are highlighted:

In AIDL implementations, the read side uses the declared type while the write side uses the runtime type, so passing an Intent subclass can cause data divergence.

Interfaces without type restrictions still execute arbitrary Parcelable constructors, and some system classes that reflect on Parcel data can be abused to alter read/write outcomes.

From a design perspective, allowing developers unrestricted control over Parcelable read/write logic introduces significant risk. Adopting stricter serialization frameworks could mitigate many of these problems, though certain low‑level IPC mechanisms will remain challenging to secure.

References

https://konata.github.io/posts/creator-mismatch/

https://github.com/michalbednarski/TheLastBundleMismatch