Next #GrapheneOS update now includes some hardening against reset attacks to prevent potential ways of bypassing our memory zeroing features.

This is a response to the exploit we previously reported to Google of forensics companies exploiting a RAM dump from fastboot firmware to brute force OS credentials in Pixels running the stock OS. While not suggested to affect GrapheneOS nor should a user be concerned, this will be an additional security enhancement for our users anyways.

Thermal reboots are unsafe reboots that don't erase memory safely. They have now been changed to perform safe shutdowns instead. It stops a threat with physical access and RAM dump capabilities from overheating the phone to force an unsafe reboot into fastboot. A reset attack protection mechanism has been enabled for supported UEFI systems. While we don't support devices using UEFI or the UEFI reset attack protection mechanism, it could come useful in later devices.

These protections will be one of multiple to kill the capability for good.

Read about the original exploit on my post on stacker news: https://stacker.news/items/385351

Reply to this note

Please Login to reply.

Discussion

Here are some further clarifications regarding the hardening and future anti-exploitation techniques from the team at #GrapheneOS:

Source: https://nitter.cz/GrapheneOS/status/1751097979866624501

"Our latest release provides another enhancement for our protection against firmware-based attacks on devices by forensics companies. We're going to be doing more similar work.

GrapheneOS has zero-on-free for the main allocator used by native code (malloc) along with the kernel page allocator and slab allocator. In particular, zeroing data in the kernel page allocator heavily limits the lifetime of data and clean reboots clear most of the OS memory.

We believe that our zero-on-free features are why forensics companies are announcing support for obtaining data in After First Unlock state for the stock OS via firmware exploits while seemingly not being able to target GrapheneOS yet, but we're rolling our more improvements.

In an earlier release this month, we replaced our auto-reboot feature with a new implementation in the init process to prevent a potential bypass through crashing core system processes. We also made it stop chain in Before First Unlock state to make low timers much more usable.

The default auto-reboot timer was reduced from our initial choice of 72 hours to 18 hours.

GrapheneOS has provided a feature for disabling USB peripherals for years. By default, we disable USB peripherals while locked. USB is very complex and has other uses than this though.

Fast charging and the low-level protocol for USB-C are extremely complex. These are largely implemented by Linux kernel drivers and the core kernel USB support along with another implementation in the non-OS firmware boot modes, not the isolated USB controller hardware/firmware. Android 12 added a device administration setting to supposedly disable USB data and a low level USB Hardware Abstraction Layer (HAL) implementation to go along with it. This does not really work as you would expect and only disables high level USB functionality like peripherals.

It also disables USB gadget support, which is already disabled by default other than device advertising itself as supporting MTP to be detected by computers by default without having MTP enabled until the user enables it. We investigated it near 12 launch but found it lacking. USB gadget support is how MTP/PTP, MIDI, tethering (Ethernet), Android 14 QPR1 webcam support and the developer options Android Debug Bridge function. By default, Android uses MTP mode with MTP disabled until user unlocks and enables it. This adds no significant attack surface.

Attack surface for low-level USB-C and charging is massive. Vulnerabilities being leveraged by forensics companies are often USB bugs. Working reset attack mitigation is barely deployed by devices meaning they can target firmware USB while device is booted into a special mode.

We proposed improvements for Pixels in Android security bug reports we filed recently. They're already working on it and we expect it will be shipped in a few months, ending the ability to get data from After First Unlock mode via special firmware modes, but not the OS itself.

To better protect the OS itself, we're working on a much lower level implementation of disabling USB support by implementing it in platform-specific drivers much lower level than the generic Linux kernel code. This will have some usability impact so it has to be a separate mode. We've also discussed the possibility of offering a toggle for disabling fast charging while locked or as a whole for further attack surface reduction. This would certainly not be enabled by default and our focus is on the always enabled or at least default enabled protections.

Our existing default-enabled USB protection disables adding new peripherals while locked. Peripherals you add while unlocked work after locking. Android's standard USB gadget control is based around approval while unlocked, which is similar. We just need to make this lower level."

thanks for your consistent updates :)