How Mismatched Parcelable Read/Write Leads to Android Exploits and How to Fix Them

Fundamentals

Android inter‑process communication mainly uses Binder, and data is transferred via Parcel, which serializes the data. The basic usage involves writing primitives and objects into a Parcel and reading them back in the same order.

When data is read, methods like readInt() and readString() interpret the raw bytes; strings are prefixed with their length, and padding is added depending on whether the length is odd or even.

Variable‑length types such as int[] or generic Object are stored with a length field followed by the elements. Parcel itself does not remember how the data was written, so any mismatched read/write sequence can corrupt the interpretation.

Problem Introduction: Read/Write Mismatch

If the serialization (write) and deserialization (read) methods differ—e.g., writing a long (8 bytes) but reading it as an int (4 bytes)—the subsequent fields become misaligned. Four common causes are:

Using types of different lengths (e.g., int vs. long).

Choosing different interfaces for the same type (e.g., writeParcelableList() vs. writeTypeList()).

Manually moving the Parcel data position with setDataPosition().

Asymmetric conditional checks that affect array length handling.

Trigger Scenario: Account Service

Account‑related components use Bundles to pass data between processes. An attacker can craft a Bundle where the first read succeeds (passing validation) but a subsequent read, after the data has been written once, yields malicious content such as a forged Intent.

The flow involves AccountManager.newChooseAccountIntent(), the framework’s ChooseTypeAndAccountActivity, and the service‑side AccountManagerService. Because the two sides run in different processes, the crafted Bundle can cause the second read to expose the malicious Intent.

Constructing the Malicious Bundle

Bundle serialization starts with three integers (magic number, length, entry count) followed by key‑value pairs. By placing a vulnerable Parcelable in the first entry and using flexible types (e.g., byte[], int[]) in the second entry, an attacker can hide a malicious Intent in the third entry.

Key ordering is based on the hash of the key strings, so the attacker must choose keys whose hash order yields the desired read sequence.

Example Exploit Code

Sample code demonstrates writing an int as long, causing the second read to interpret the extra bytes as a different type, eventually exposing the malicious Intent.

Additional Tricks

Debugging can be aided by writing a mirror class that logs the Bundle read/write process. Adding the androidx.core:core dependency allows hex dumping of the entire Parcel.

Mitigation Measures

Google introduced a new mechanism in Android 13 that forces length fields for variable‑size types, reducing the impact of misaligned reads. Patches were back‑ported to Android 12 for known CVEs. Further hardening includes:

Changing OutputConfiguration to avoid catching exceptions and to use createIntArray instead of readList.

Preventing ClipData from carrying arbitrary Parcelable extras.

Updating WindowContainerTransaction to use readTypedList with a fixed CREATOR.

References

https://github.com/michalbednarski/IntentsLab/issues/2#issuecomment-344365482

https://github.com/michalbednarski/ReparcelBug2