Hack, Patch, Repeat: Insider Tales from Android's Security Team

Hack, Patch, Repeat: Insider Tales from Android's Security Team

Speakers: Maria Uretsky, Camillus Cai

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch on YouTube

Reading time: ~9 minutes

TL;DR

Android's attack surface is far larger than most researchers appreciate — it spans Google, AOSP, OEMs, carriers, chipset vendors, and third-party apps, all under a multi-party consent model enforced through Linux-level isolation and SELinux. The Android Vulnerability Rewards Program paid out $2.7 million in 2024 (with a single chain earning $265,000), and the Google security team uses that pipeline to fix bugs from the root — across Android TV, Auto, and Wear OS simultaneously. This talk walks through real VRP-submitted vulnerabilities, explains exactly where they live in the architecture, and gives researchers the map they need to find the next ones.

Introduction

Android runs on more than three billion active devices. But "Android" is not a single codebase or a single entity's responsibility — it is a layered ecosystem involving Google, the Android Open Source Project (AOSP), original equipment manufacturers (OEMs), chipset vendors, carriers, and third-party app developers, all building on top of each other. Securing it requires understanding not just what each layer does but where the trust boundaries lie between them.

Maria Uretsky, engineering manager on Android's security team, and Camillus Cai, a security engineer on the same team, brought that map to BSidesSF 2025 with a presentation that moved from ecosystem overview to security model architecture to live vulnerability walkthroughs — all designed to help external researchers find and report high-value bugs to the Android VRP.

What Android Actually Is (And Why That Matters for Research)

▶ Watch: The Android ecosystem explained (03:00)

Most people think of Android as the software on their phone. The actual picture is considerably more complex. AOSP — the foundational open-source stack — is a separate entity from Google; Google is a contributor but the two are kept intentionally distinct. On top of AOSP sit the Linux kernel (including Google's Generic Kernel Image, shipped to give OEMs a unified foundation), OEM customizations, chipset drivers from hardware vendors, Google Mobile Services (GMS, meaning Google's apps and services), carrier configurations, and bundled third-party apps.

OEMs run compatibility testing against Google's Compatibility Definition Document (CDD), backed by the Vendor Test Suite (VTS) and the Security Test Suite (STS). Passing these tests is required to receive Google's signing key and ship a certified device. But the stack doesn't stop there — users then install more apps of their own, adding yet another layer.

From a security research perspective, each of these layers represents a different set of trust boundaries and interfaces. "As security professionals looking at this web, you're probably already thinking about the multitude of touch points and interfaces and trust boundaries, each a potential area for hacking or security research," Uretsky noted. The Android Platform Safety team maintains teams dedicated to hardening each of these edges. External researchers — through the VRP — are a critical partner in finding what the internal team misses.

The Android VRP: Severity, Payouts, and the Power of Proof-of-Concept

▶ Watch: VRP structure and rewards (10:00)

The Android Vulnerability Rewards Program rewards based on two factors: report severity and report quality. Cai and Uretsky were direct about what quality means in practice: a minimal reproducible proof-of-concept (PoC) allows engineers to go from submission to root cause significantly faster. Without a PoC, "even if the bug is of a critical severity, there is not much we can do. We can try to work around it, but as long as we don't have the PoC, we don't have proof that this is actually happening."

The severity tiers map to concrete classes of impact. Critical bugs include remote secure boot bypass — which undermines foundational trust in the device's boot chain — and remote arbitrary code execution in the kernel. High bugs include factory reset protection (FRP) bypass, which diminishes anti-theft protection, and prevention of emergency service access, which directly endangers users. The team's detailed guidelines, publicly available on the Android developer site, also draw important distinctions: permanent denial of service of a device rates high severity; a recoverable boot loop with no data loss rates NSI (Negligible Security Impact). Knowing these distinctions before investing in research is critical for focusing work on high-reward targets.

The team also values exploit chains at a premium — not just because they represent more work, but because "they're not a collection of vulnerabilities, they're a window into the attacker's mind. We understand how attackers think and progress." In 2024, the program paid $2.7 million total, with the highest single reward reaching $265,000.

The Cropalypse bug — CVE published March 2023 — illustrated the VRP's systemic value. A researcher demonstrated they could uncrop any Android screenshot, recovering image content the user intended to hide. The root cause was a three-part interaction: Android 10 refactored screenshot handling from truncate mode to append mode file writes, PNG's non-strict format tolerated the resulting valid-but-oversized file, and no one anticipated the combination. Because the researcher reported responsibly before publishing their uncropping tool, Google fixed it at the source and notified Android TV, Auto, and Wear OS simultaneously — before the CVE made international headlines.

The Security Model: Process Isolation, Binder, and Multi-Party Consent

▶ Watch: Android's security architecture (20:00)

Camillus Cai's section of the talk was an architectural orientation, explicitly designed to give researchers intuition about where bugs live in the stack.

Android is built around multi-party consent: the human user, the app developer, the OS itself, and (on corporate devices) an enterprise administrator must all agree before actions are permitted. The OS is opinionated about direction — enterprise administrators can only restrict device capabilities, not expand them beyond what users have consented to.

The primary security boundary in Android is the process, not the Java Virtual Machine. The JVM is not a security boundary; extracting code into a native library does not achieve isolation. Actual isolation requires running code in a separate process, using Android's isolated_process mechanism. When an app is installed, it receives a unique Linux user ID (UID), and the kernel enforces the app sandbox through file system permissions and SELinux — preventing processes with different UIDs from accessing each other's resources.

System Server is the architectural chokepoint. It is the first process forked from Zygote, runs with UID 1000, manages Android permissions, controls app lifecycle, and handles notifications. "From a security perspective, it is the gatekeeper for many sensitive operations and data. Accordingly, this is also where the typical Android bug is going to be found."

File-based encryption determines what data is accessible at any given moment. There are two storage partitions: device-encrypted (available after boot, for things like alarms and emergency calls) and credential-encrypted (available only after the first post-boot unlock). The Before First Unlock (BFU) vs. After First Unlock (AFU) distinction has direct security implications: under AFU, a kernel exploit can potentially expose the full contents of credential-encrypted storage, because the decryption key is now in memory. "If you believe that your device is imminently at risk, the best way to secure it is to simply reboot it."

Real Vulnerabilities from the 2024 VRP

▶ Watch: Live vulnerability walkthroughs (32:00)

Cai walked through three classes of bugs the team dealt with in 2024, all fixed and disclosed in Android Security Bulletins.

Cross-user permission confusion. Android implements Users as a system-level feature — a family sharing a tablet gets separate locked spaces, each with their own credential-encrypted partition. But hundreds of system APIs must individually maintain user isolation, and in a large codebase, mistakes accumulate. The most common failure is forgetting to check whether a caller has permission to interact across users. The 2024 example: an evil app returns a content URI during the profile picture picker flow, but instead of pointing to the requester's own picture, it uses another user's UID. The Settings app — which legitimately has cross-user access — loads the other user's picture and hands it back. Fix: verify that the resource is owned by the requester and load it with the requester's context.

Desync from persistence (boot loop variant). Android components persist state to XML files or SQLite databases, and these files need to be read successfully on boot. A missing sanitization or error-handling failure can write data that can't be parsed back, causing the OS to fail on every boot — a permanent boot loop that requires a factory reset. The team fixed multiple instances of this in 2024.

Desync from persistence (silent permission regrant). The more subtle variant: an attacker injects a payload into a data structure that is valid in memory but fails serialization. Because serialization happens asynchronously and errors aren't bubbled up, subsequent writes to the same structure also fail silently. In the demonstrated example, a malicious app that has gained permission to read notification content (which includes OTPs) calls a notifications API with garbage data. This causes the backing XML file to desync from memory. When the user revokes the permission, it appears to work during the session — but the revocation never persists to disk. On the next reboot, the OS reads the stale XML and re-grants the permission. "As a user, you would probably think that you have revoked the permission, but in fact it didn't stick."

USB kernel exploit (from an active exploit chain). This bug originated from threat intelligence about an actively exploited chain used by a real threat actor. When a USB device is plugged in, the HID multi-touch driver allocates memory using kmalloc — which does not zero-initialize. If the USB device replies with data shorter than the allocated buffer, the uninitialized remainder is left in place and later reflected back to the USB device. A malicious USB device (software-emulated, not actual hardware) can use the leaked uninitialized kernel memory — which may contain kernel addresses — as input to a subsequent exploit stage. The fix: use kzalloc, which zero-initializes on allocation.

Notable Quotes

"If you report the vulnerability to us, we are able to fix it from the source. We are able to work with Android verticals — Android TV, Auto, Wear — and make sure that if they are affected, they're notified and we'll work with them to fix it." — Maria Uretsky (14:00)

"The Java Virtual Machine is not a security boundary. Don't rely on Java's security manager class to isolate code. If you want to achieve isolation, the best thing to do is to put it in a separate process." — Camillus Cai (22:00)

"If you believe that your device is imminently at risk, the best way to secure it is to simply reboot it. This puts your device back into Before First Unlock state and puts your data back at rest." — Camillus Cai (28:00)

Key Takeaways

• Android is an ecosystem, not a product. Bugs can exist at the AOSP layer, in OEM customizations, in chipset drivers, in GMS, or in system services — researchers should understand which layer they're targeting and what severity class it maps to.
• System Server is the highest-value target for VRP submissions. It manages permissions, app lifecycle, and cross-user isolation, and its size means it accumulates mistakes.
• Desync bugs are harder to catch than logic bugs. When in-memory state and disk state diverge silently, user-visible behavior can appear correct while security invariants are violated — permission revocations that don't stick, configurations that revert on reboot.
• BFU vs. AFU is a practical security distinction. A device in Before First Unlock state is significantly harder to extract data from even if the attacker achieves kernel code execution; knowing this matters for both attackers and defenders.
• A PoC is worth more than a description, even for critical bugs. The VRP rewards report quality alongside severity — a clear, minimal proof-of-concept dramatically accelerates the path from submission to patch.