Full Report
While reading various security advisories the author missed while on vacation, there noticed a Pixel anti-rollback notice. This indicated that a vulnerability occurred in the bootloader of the device, making it a major risk and adding an anti-rollback feature to it. Since there was no public information besides there being a bug and it says RCE, the author of the post decided to find and exploit the bug. The ARM specification for the boot process is going from the Primary Boot Loader (PBL) ->BL1->->BL2->BL31->Trustzone(TZSW) and ABL. BL1 performs late architectural and platform specific initialization and runs the second BL image, which simply loads BL3. BL3 sets up he runtime services for the CPU and helps pass control to the operating system. The bootloader is in likely in BL1 because its the furthest down in the chain that isn't in ROM. To find the vulnerability, they downloaded versions before and after the patch. By comparing with bindiff, it probably wouldn't be the hardest thing in the world to find the patch for the security issue. They used bindiff on the most of the fastboot commands for each of the binaries. From this, they identified a small bit of code that was removed from the command handlers. There were low level commands that the fastboot console has access to - flash:raw. However, part 2 appears to refer to a vulnerability in the bootloader but doesn't actually mention what it is. Instead, they claim there's a vulnerability that allows for some sort of write primitive. So, I'm a little confused here. To build a working exploit, they setup an emulator with Unicorn. The typical workflow for emulation is creating the emulator, setting up the memory in the same way as the image, initializes the device and execution. To top it off, hooks must added to native functionality that cannot be emulated. With the debugging environment setup, the hacking can be done. To get a nice read/write primitive, we can probably reuse existing code. The internal commands (without handlers) download for reading content and upload for writing content. Overall, the posts are mildly confusing, as not everything is laid out perfectly. In particular, the vulnerability is not defined well and the wording in the second post can be confusing. However, the process for reverse engineering, emulation and exploit methodology was very interesting!
Analysis Summary
# Vulnerability: Unspecified Pixel Bootloader RCE Leading to Anti-Rollback Enforcement
## CVE Details
- CVE ID: Not specified in the text. (The text mentions a bug fixed that forced anti-rollback, often linked to Pixel Security Bulletins, but no specific CVE is provided for this research effort.)
- CVSS Score: Unknown. (Severity implied as Major/RCE level, suggesting High/Critical)
- CWE: Not specified in the text.
## Affected Systems
- Products: Google Pixel 6 (Implied due to the context of the anti-rollback notice specific to this device).
- Versions: Bootloader versions prior to the security patch mentioned, as the existence of the flaw necessitated the introduction of an anti-rollback measure.
- Configurations: Devices running Android on Pixel 6 hardware vulnerable in the bootloader (likely BL1 stage).
## Vulnerability Description
The vulnerability resides in the bootloader of the Google Pixel 6, specifically located in the lower stages of the boot chain (likely BL1, which is the furthest from ROM). While the exact nature of the RCE (Remote Code Execution) flaw is not publicly detailed in the summary, the researcher identified that a patch was applied to the bootloader which removed a small section of code associated with certain fastboot command handlers (e.g., `flash:raw`). Successful exploitation is suggested to lead to a **write primitive**, potentially escalating privileges up to the Titan-M security processor.
## Exploitation
- Status: Research/Internal Exploitation. (The researcher built an emulator setup using Unicorn to analyze and attempt exploitation. The exploit is currently private.)
- Complexity: Medium to High (Requires deep reverse engineering of bootloader binaries, precise emulation setup, and ROP/primitive development).
- Attack Vector: The initial RCE potential suggests a Remote vector, though the specific conditions of the fastboot flaw exploitation are often Local or require interaction via interfaces accessible early in the boot process.
## Impact
- Confidentiality: High (Potential for Data Exfiltration/Full device compromise).
- Integrity: High (Potential for arbitrary code execution and modification of critical system components/firmware).
- Availability: High (Potential for device bricking or persistent compromise).
## Remediation
### Patches
- Patches were issued by Google which triggered the implementation of an anti-rollback mechanism, preventing downgrades to vulnerable versions. Specific patch versions or Android Security Bulletins are not detailed in this summary.
### Workarounds
- Enforcing the latest firmware updates to ensure the anti-rollback feature is active and the vulnerability is patched (though this prevents rolling back to older, unpatched functionality desired by some researchers).
## Detection
- Detection methods are not specified, but monitoring for abnormal fastboot operations or unauthorized modification attempts during the early boot stages could serve as an indicator.
- Indicators of compromise (IOCs) were not provided due to the private nature of the exploit.
## References
- Contextual reference to Pixel Security Bulletin: hxxps://source.android.com/docs/security/bulletin/pixel/2022-05-01
- Mention of forced anti-rollback: hxxps://arstechnica.com/gadgets/2022/08/new-security-measures-make-android-13-for-the-pixel-6-a-one-way-update/
- Related research mentioning Pixel 6 hardening: hxxps://github.com/polygraphene/DirtyPipe-Android
- Research Blog (Part I): hxxps://eshard.com/posts/pixel6bootloader-1
- Research Blog (Next Step Mentioned): hxxps://eshard.com/posts/pixel6bootloader-2