Fighting Cavities: Securing Android Bluetooth by Red Teaming

Fighting Cavities: How Google's Android Red Team Breaks Bluetooth to Secure It

Speakers: Rishika Hooda, Xuan Xing, and Jeong Wook Oh ("Matt") (Google Android Red Team)

Conference: OffensiveCon 2025 — May 16–17, 2025, Berlin

YouTube: https://www.youtube.com/watch?v=PgnRkL0sd0w

Reading time: ~10 minutes

TL;DR

Google's Android Red Team conducted a structured offensive security engagement against the Android Bluetooth stack — the open-source Fluoride/AOSP implementation running in a privileged system process — and discovered multiple critical and high-severity vulnerabilities including two remote code execution bugs. All findings have been patched and distributed via the Android Security Bulletin. The team combined manual code review, custom host-based fuzzing pipelines, CodeQL static analysis, and KLEE symbolic execution, with manual review accounting for roughly half the critical discoveries including the two RCE bugs demonstrated at the talk.

Introduction

Bluetooth is present on virtually every modern mobile device, wearable, IoT sensor, and connected vehicle. The Android Bluetooth stack — implemented in the open-source Fluoride codebase within AOSP — runs as a privileged process because it requires special operations like injecting keyboard input from a connected Bluetooth keyboard. A successful attacker who achieves remote code execution inside that process inherits substantial system-level access and a launchpad for further privilege escalation.

The Android Red Team at Google, part of the broader Android Privacy and Security organization, treats Bluetooth as one of its highest-priority targets precisely because of this combination: massive attack surface, thousands of pages of specification complexity, proximity-independent (for some attack vectors) reachability, and high-privilege execution context. Their OffensiveCon 2025 talk is an unusually transparent account of an internal red team engagement — from threat modeling through exploit development — and includes concrete details about two RCE vulnerabilities demonstrated live.

Threat Model: Scoping a Thousand-Page Attack Surface

▶ Watch: Threat Modeling and Attacker View (4:00)

Xuan Xing, Android Red Team Manager, presented a deliberately simplified "attacker's view" of the Bluetooth stack. The Android ecosystem's Bluetooth security domains break into three layers: the AOSP-sourced Bluetooth stack in the system partition, vendor-partition firmware, and application-layer code. The red team focused exclusively on the first layer — the open-source stack — because it has source code available for analysis and represents the most impactful target given its privileged process context.

Even within that layer, scoping is necessary. The team divided targets into pre-authentication and post-authentication components. Pre-authentication surfaces — those reachable without any pairing handshake — received first priority because they enable zero-click attacks. Post-authentication surfaces were included because of the social engineering practicality: in dense environments (offices, conference halls), users routinely encounter long lists of Bluetooth devices and can be tricked into pairing with a malicious one without meaningful confirmation feedback.

The threat model covers two attacker positions: an adversary-in-the-middle on an existing Bluetooth connection, and an attacker with a malicious Bluetooth device attempting to trigger pairing or send raw packets. The desired outcomes range from denial of service and information disclosure to full remote code execution inside the Bluetooth privileged process, with an eye toward eventual process escape.

Methodology: Manual Review, Fuzzing, and Static Analysis

▶ Watch: Research Methodology (8:00)

The engagement lasted approximately two months and used three complementary techniques.

Manual Code Review was the dominant method, responsible for roughly half of all findings — including both RCE bugs. The team explicitly favors manual review for logic bugs, race conditions, and end-to-end vulnerability scenarios that span multiple components. These are the vulnerability classes that automated tools handle worst. The limitation is scalability: manual review requires deep domain knowledge to bootstrap, produces one-time results that don't automatically catch regressions, and cannot keep pace with active feature development.

Host-Based Fuzzing addressed scalability. Rather than treating the Bluetooth stack as a monolithic fuzzing target, the team built component-level fuzzers targeting individual protocol implementations. The fuzzers run on standard Linux hosts — Android's "host" build environment — rather than physical devices, enabling integration into Google's cloud-based continuous fuzzing infrastructure. Coverage across individual Bluetooth stack components reached approximately 50–60%, which the team noted represents near-maximum useful coverage given that only inbound (attacker-controlled) code paths are security-relevant, not outbound data handling. These fuzzers are still running continuously in Google's internal infrastructure at the time of the talk.

Static Analysis via CodeQL and KLEE supplemented the other methods. The team wrote CodeQL queries targeting a recurring Bluetooth vulnerability pattern: fixed-size stack, global, or heap buffers iterated with out-of-bounds read or write operations — a common mistake in C/C++ Bluetooth implementations. These queries rediscovered known issues and found new ones, validating the approach. KLEE symbolic execution was used for formal verification experiments on selected components, with mixed results: it successfully reproduced and found some issues, but the path explosion problem and difficulty integrating invasive build changes into Google's engineering pipeline limited its CI utility.

▶ Watch: Fuzzing and Coverage (10:01)

The team also contributed upstream fixes to open-source tools used in the security community — CodeQL, Uber Tools, Wireshark, Scapy, and Frida — as part of their philosophy of feeding research back to the community.

The Vulnerability Portfolio

▶ Watch: Critical and High Findings (14:00)

The engagement produced multiple critical and high-severity findings across various Bluetooth stack components, plus a range of moderate-severity issues surfaced by the fuzzers. The talk does not enumerate individual CVEs for all findings, but Rishika Hooda confirmed that all issues are now patched and distributed through the Android Security Bulletin. Affected users were directed to apply the latest patches corresponding to their device's Security Patch Level (SPL).

The critical findings included two RCE vulnerabilities, both discovered by manual code review, which Jeong Wook Oh ("Matt") demonstrated in the second half of the talk. These vulnerabilities reside in pre-authentication or post-authentication components of the AOSP Bluetooth stack and, if successfully exploited, deliver code execution within the Bluetooth privileged process without requiring the target to explicitly confirm any interaction beyond normal Bluetooth proximity.

Patching Bluetooth in Android proved more complex than typical Android vulnerability patches. The talk acknowledged that Bluetooth represented a "specifically complex target in terms of patching" — a point the team committed to addressing in detail in later slides — owing to the interplay between AOSP changes, OEM vendor integrations, partner testing cycles, and Security Patch Level inclusion requirements.

Exploit Development: From Crash to RCE

▶ Watch: Exploit Development (16:00)

Jeong Wook Oh presented the exploit development portion of the talk, walking through how a discovered crash primitive was converted into reliable remote code execution against the Bluetooth privileged process. The Bluetooth process runs in a confined context within the Android security model, but its privilege level — including the ability to inject input events from connected devices — means a successful compromise has meaningful impact even before any privilege escalation.

The team emphasized that both demonstrated RCE bugs required no memory corruption in the traditional sense of arbitrary stack/heap corruption; rather, they exploited structural weaknesses in protocol handling logic within the Bluetooth stack that could be triggered by a remote device (either pre-pairing or post-pairing). This aligns with the broader observation that Bluetooth's specification complexity creates logic-level vulnerabilities that are often harder to find by fuzzing than by careful manual analysis of state machines and protocol flows.

Defensive Improvements Driven by the Engagement

▶ Watch: Mitigations and Improvements (40:00)

Beyond vulnerability discovery, the red team's engagement produced concrete defensive improvements in the Android Bluetooth codebase. This feedback loop — from offensive findings to hardening — is presented as the primary justification for conducting internal red team work rather than relying exclusively on external bug bounty programs or academic research.

Specific mitigations implemented following the engagement include hardening of protocol state machines in components where the red team identified reachable logic-error conditions, improvements to the Bluetooth process's privilege boundaries to limit blast radius in the event of future compromises, and expanded fuzzing coverage targeting the specific components where manual review found the most severe issues.

The team's fuzzers, upgraded and tuned during the engagement, continue running in Google's continuous integration pipeline, providing ongoing regression detection as the Bluetooth codebase evolves.

Notable Quotes

"Bluetooth is probably one of the best feature developed by mobile or used in your mobile — your phone, your watch, your IoT, even cars, everything is connected via Bluetooth these days, which makes it even more interesting attack vector." — Rishika Hooda ▶ 2:00

"Manual code review is still our main method because it has discovered very, very hard to find issues using other methods." — Xuan Xing ▶ 8:00

"Even if you have one hundred percent line coverage, there is still a lot missing from the fuzzing, so there is still room to improve." — Xuan Xing ▶ 12:00

Key Takeaways

• The Android Bluetooth stack (AOSP Fluoride) runs as a privileged system process, making successful RCE within it a high-impact event capable of injecting input events and enabling further privilege escalation.
• Manual code review discovered approximately half of all critical and high findings, including both demonstrated RCE bugs — confirming that logic bugs, race conditions, and multi-component state machine flaws remain resistant to automated fuzzing.
• Host-based component-level fuzzing (integrated into Google's cloud CI pipeline) provided scalable regression detection at 50–60% meaningful coverage, and continues running continuously post-engagement.
• CodeQL queries targeting the Bluetooth stack's characteristic fixed-buffer/out-of-bounds pattern both found new issues and validated manual findings, demonstrating effective variant analysis.
• All findings are patched and distributed via the Android Security Bulletin; affected users should update to the latest Security Patch Level to receive the fixes.