Bypassing Android Intent Destination Checks via TOCTOU Race Conditions

TLDR: This research demonstrates how to exploit Time-of-Check to Time-of-Use (TOCTOU) race conditions in Android’s AccountManagerService to bypass destination checks and achieve privilege escalation. By manipulating component states and intent filters, an attacker can force the system to resolve an intent to a privileged activity after the initial security check has passed. Pentesters should focus on IPC mechanisms that perform multi-step validation, as these are prime targets for race-based exploitation.

Android inter-process communication (IPC) relies heavily on Intents, but the security model surrounding them is far from bulletproof. While developers often implement destination checks to ensure an Intent is only handled by an authorized component, these checks are frequently vulnerable to race conditions. The core issue lies in the gap between the moment a security check is performed and the moment the target component is actually launched. If an attacker can alter the state of the system during this window, they can redirect the execution flow to a privileged activity that should have been off-limits.

The Mechanics of the Race

The vulnerability centers on the AccountManagerService and its handling of Intents. When an application requests to add an account, the service performs a series of checks to verify the caller's identity and the legitimacy of the target component. The flaw exists because the resolution process is not atomic.

The system performs an initial check using resolveActivity to ensure the target is valid and authorized. However, the actual launch of the activity happens in a subsequent, separate step. By using a background thread to toggle the enabled state of a component via PackageManager.setComponentEnabledSetting, an attacker can effectively "vanish" the benign component that passed the initial check and replace it with a malicious one just as the system proceeds to the launch phase.

This technique is a classic TOCTOU attack, but applied to the Android framework's IPC resolution logic. The window of opportunity is small, but on many devices, it is wide enough to be reliably exploited. The researcher demonstrated that by flooding the system with requests and precisely timing the component state change, the race condition can be won consistently.

Exploiting the Parcel Mismatch

A critical component of this exploit is the manipulation of Parcel objects within the Intent. When an Intent is passed between processes, it is serialized into a Parcel. If the developer does not correctly handle the Parcel data, specifically regarding the length of the data being read, it can lead to a mismatch between what the AccountManagerService sees and what the Settings application eventually processes.

This mismatch allows an attacker to supply a "self-changing" Bundle. By crafting a payload where the certLength is set to -1, the attacker can bypass the checkKeyIntent validation. This effectively tricks the system into accepting an Intent that would otherwise be rejected. The following snippet illustrates the vulnerability in the readFromParcel implementation:

// Vulnerable implementation of readFromParcel
int v0 = in.readInt();
if (v0 > 0) {
    byte[] v1 = new byte[v0];
    this.certificate = v1;
    in.readByteArray(v1);
}

When the certLength is manipulated, the deserialization process fails to properly validate the object, allowing the attacker to inject arbitrary data into the Intent. This is the foundation for CVE-2025-32321, which highlights the danger of trusting deserialized data in IPC.

Real-World Impact and Testing

For a pentester, this vulnerability is a goldmine. During an engagement, you should look for any IPC interface that performs a "check-then-act" pattern. If you see a service that validates an Intent and then later calls startActivity or startService, you have a potential TOCTOU candidate.

To test for this, you need to map out the IPC calls using Perfetto to identify the timing of the security checks. Once you have the timing, you can write a script to trigger the race condition. The goal is to force the system to resolve your malicious intent instead of the one it originally validated. The impact is significant: you can escalate privileges to the level of the system service, allowing you to perform sensitive actions like modifying lock screen credentials or making unauthorized phone calls.

Defensive Considerations

Defending against these race conditions requires moving away from multi-step validation. The most effective fix is to make the Intent resolution and the component launch an atomic operation. Developers should use explicit Intents whenever possible, setting the target component directly using setComponent or setPackage. This removes the need for the system to perform a dynamic resolution, which is where the race condition is introduced.

Furthermore, system services must ensure that the security context of the caller is verified at the exact moment of execution, not just at the start of the request. Relying on cached results or snapshots of the system state is dangerous, as these can be invalidated by concurrent operations.

The persistence of these vulnerabilities in the Android Open Source Project (AOSP) codebase is a reminder that even well-understood patterns like TOCTOU remain relevant in complex systems. As researchers, we must continue to push for more robust IPC designs that prioritize atomicity and explicit intent handling. If you are hunting for these bugs, focus on the interaction between system services and the PackageManager, as this is where the most interesting race conditions are currently hiding.