Our latest release provides another enhancement for our protection against firmware-based attacks on devices by forensics companies.
https://grapheneos.social/@GrapheneOS/111825976031359694
This replaces emergency reboots triggered by overheating with regular reboots. 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.
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.
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.