The Hidden RCE Surfaces That Control the Droids

Overview: Researchers from Chaitin Security Lab present an investigation into overlooked remote code execution (RCE) attack surfaces across the Android operating system. While modern Android has fortified standard attack vectors—such as sandboxing browser WebViews and re-architecting media parsers following Stagefright—the speakers identify persistent vulnerabilities in enterprise configuration components and legacy file format handlers. Specifically, they dissect the Android Open Source Project (AOSP) Proxy Auto-Configuration (PAC) service, demonstrating how an un-isolated V8 JavaScript engine executing in a platform application context exposes devices to remote exploitation.

Key Topics: - Classification of Android remote attack vectors: Wi-Fi, NFC, Bluetooth, baseband, and file/format parsing - Architecture of Android AOSP Proxy Auto-Configuration (PacService, PacProcessor, libpac) - Security architectural flaw: un-isolated V8 JavaScript engine instances running in platform application contexts - Exploitation of upstream-downstream patch gaps between Chromium V8 and AOSP external/v8 - Weaponizing CVE-2020-0240 (integer overflow in NewFixedDoubleArray) to bypass JIT mitigations and gain RCE

Technical Details: While Android isolated application WebViews in Android 8.0 (Oreo) and partitioned media parsing services, the speakers discovered that an un-isolated V8 JavaScript engine remained operational within the platform application context via the Proxy Auto-Configuration (PAC) mechanism. PAC enables Wi-Fi access points and enterprise networks to distribute a JavaScript file defining a FindProxyForURL(url, host) function to automate routing. In AOSP (packages/services/PacProcessor), network proxy requests invoke PacNative.makeProxyRequest(), which calls into libjni_pacprocessor.so and libpac.so to initialize a V8 context and execute the PAC script.

The researchers uncovered multiple severe structural flaws in this architecture. First, AOSP maintained an independent downstream branch of V8 in external/v8 that suffered from substantial patch gaps; security patches merged into upstream Chromium were delayed by months or years in Android, leaving known n-day exploits viable on deployed devices. Second, although Google attempted to neutralize JavaScript exploits by disabling JIT compilation via the --no-opt flag, non-JIT memory corruption bugs remained fully exploitable. Third, because PacProcessor executed within the privileged platform application context rather than an isolated sandbox, code execution inside the engine directly yielded platform privileges.

The authors demonstrated remote code execution using CVE-2020-0240 (Chromium issue 938251), an integer overflow in NewFixedDoubleArray. Because the allocation routine failed to account for negative length values, an attacker could supply crafted parameters to create an array with an out-of-bounds length without requiring JIT optimizations. This primitive provided arbitrary memory read and write capabilities. By overwriting an executable WebAssembly (Wasm) memory page with native shellcode, the researchers redirected execution flow to gain arbitrary code execution in the platform application context. While PacProcessor lacks SMS or storage permissions, gaining platform context provides an ideal launchpad to target local kernel drivers and IPC interfaces to achieve complete device takeover.

Key Takeaways: Disabling JIT compilation does not prevent JavaScript engine exploitation when core array allocations and memory handling functions harbor integer overflows or logic bugs. Downstream code repositories in large operating systems (such as AOSP external/v8) must maintain aggressive upstream synchronization to prevent extended patch gaps from exposing users to known exploits. Legacy system utilities and network configuration services that execute untrusted scripts must be strictly quarantined within restricted, multi-process application sandboxes.

(AI summary — Gemini Flash)