Reanimating LaunchAnyWhere: Exploiting TOCTOU Races in Android IPC

TLDR: This research revives the classic LaunchAnyWhere privilege escalation by exploiting a Time-of-Check to Time-of-Use (TOCTOU) race condition in Android’s AccountManagerService. By manipulating the intent resolution process through malformed manifests and thread-based component state toggling, an attacker can force the system to execute privileged activities. Pentesters should audit IPC-heavy system services for similar race windows where intent validation and execution are decoupled.

Android security is often a game of cat and mouse, where developers patch a vulnerability only for researchers to find a new way to trigger the same underlying logic flaw. The "LaunchAnyWhere" class of vulnerabilities, which allows an unprivileged app to trigger sensitive, protected activities, was thought to be largely mitigated by destination checks. However, the recent research presented at DEF CON 33 proves that these checks are only as strong as the atomicity of the resolution process. When the system checks an intent and then executes it, a race window exists. If you can manipulate the component state during that window, you can bypass the security boundary entirely.

The Mechanics of the Race

At the heart of this exploit is the AccountManagerService. When an application requests to add an account, it sends an intent to the system. The system, in turn, performs a series of checks to ensure the calling application has the necessary permissions to interact with the target component. The vulnerability arises because the validation of the intent and the actual execution of the startActivity call are not atomic.

The researcher identified that by using a malformed Android manifest—specifically one packed with a massive number of intent filters and categories—they could artificially inflate the time the system spends resolving the intent. This is not just a performance issue; it is a functional exploit primitive. By forcing the PackageManagerService to perform a linear search through thousands of entries, the attacker creates a reliable, multi-hundred-millisecond window to race the system.

During this window, the attacker uses a secondary thread to toggle the state of their own malicious component using PackageManager.setComponentEnabledSetting. By disabling the component that passed the initial check and enabling a privileged target component just before the system executes the startActivity call, the attacker forces the system to launch a component that should have been off-limits.

Technical Implementation

To reproduce this, you need to understand how the system resolves intents. The resolveActivity function is the pivot point. If you can influence the result of this function between the check and the use, you win.

// Simplified logic of the race condition
if (checkKeyIntent(intent)) { // Time of Check
    // Race window: manipulate component state here
    startActivity(intent);    // Time of Use
}

The researcher utilized Perfetto to profile the IPC latency between the AccountManagerService and the Settings application. By visualizing the trace, they confirmed that the resolution process takes long enough on lower-end devices to make the race condition deterministic. On high-end hardware, the window is tighter, but still exploitable with precise timing.

This technique is a textbook example of A01:2021-Broken Access Control, specifically where the system trusts the state of an object that can be modified by the user. The impact is significant: an attacker can trigger activities that perform sensitive actions, such as modifying lock screen credentials or initiating unauthorized phone calls, effectively bypassing the Android permission model.

Real-World Pentesting Context

During a mobile security assessment, you should look for any system service that accepts an intent, validates it, and then passes it to another component. If you see a pattern where the service performs a resolveActivity call followed by a startActivity call, you have a potential TOCTOU candidate.

Use CodeQL to query the AOSP codebase for these patterns. Specifically, look for instances where the result of an intent resolution is stored and then used later. If the target component is not explicitly set in the intent, the system is performing an implicit resolution, which is exactly what you want to target. For closed-source vendor code, JEB Decompiler is your best friend for identifying these same patterns in the vendor-specific AccountManager or Settings implementations.

The researcher also highlighted that this is not a one-off bug. They discovered similar vulnerabilities in other parts of the AOSP, leading to the assignment of CVE-2025-32321 and CVE-2025-8192. This confirms that the pattern of "check then act" is pervasive in complex IPC chains.

Defensive Considerations

For blue teams and Android framework developers, the fix is straightforward but requires discipline: make the intent explicit. By using setComponent or setPackage before the intent is passed to the system, you eliminate the resolution ambiguity that the attacker exploits. If the intent is already explicit, the system does not need to perform a search, and the race window vanishes.

Furthermore, system services should avoid relying on the state of the PackageManager for security-critical decisions if that state can be modified by the caller. If a service must resolve an intent, it should do so in a way that is immutable or protected from concurrent modification.

This research serves as a reminder that even well-understood vulnerability classes like LaunchAnyWhere are never truly dead. They just evolve to hide in the gaps between system calls. As a researcher, your next step should be to map out the IPC graph of your target device and look for these gaps. If you find a service that takes an intent and performs a multi-step resolution, you have found your next target.