April release of the Pixel boot chain firmware includes fixes for 2 vulnerabilities reported by GrapheneOS which are being actively exploited in the wild by forensic companies:
https://source.android.com/docs/security/bulletin/pixel/2024-04-01 https://source.android.com/docs/security/overview/acknowledgements
These are assigned CVE-2024-29745 and CVE-2024-29748.
CVE-2024-29745 refers to a vulnerability in the fastboot firmware used to support unlocking/flashing/locking. Forensic companies are rebooting devices in After First Unlock state into fastboot mode on Pixels and other devices to exploit vulnerabilities there and then dump memory.
We proposed zeroing memory in firmware when rebooting to fastboot mode to wipe out the whole class of attacks. They implemented this by zeroing memory when booting fastboot mode. USB is only enabled by fastboot mode after zeroing the memory is completed, blocking these attacks.
GrapheneOS already implemented defenses against this attack before we became aware of it. After becoming aware of this attack against Pixels running the stock OS, we improved our existing defenses and added new ones alongside reporting the firmware weaknesses to get those fixed.
CVE-2024-29748 refers to a vulnerability providing the ability to interrupt a factory reset triggered by a device admin app. It appears they’ve implemented a partial solution in firmware. See https://grapheneos.social/@GrapheneOS/112162304896898942 about ongoing work we spotted on wipe-without-reboot support.
GrapheneOS has been working on a duress PIN/password feature for a while, and as part of that we already implemented our own wipe-without-reboot system. We care a lot about doing things properly and the way this was done in existing apps and operating systems was highly insecure.
Can see the announcement of these being exploited in the wild at https://source.android.com/docs/security/bulletin/pixel/2024-04-01#Announcements.
In addition to them working on our proposal to implement wipe-without-reboot, we’ve spotted work on our other suggestions such as wiping key derivation results from memory after unlocking.
In the near future, we’ll be shipping a properly secure implementation of a duress PIN/password along with a properly secure panic wipe based on wiping without requiring a reboot. We also plan to make device admin API use our wipe-without-reboot approach until Android ships one.
Our baseline defenses against attacks aiming to extract data from After First Unlock state devices are our generic exploit protection features:
https://grapheneos.org/features#exploit-protection
Wiping freed memory in kernel/userspace helps beyond exploit mitigation by avoiding having data kept around.
Our auto-reboot feature starts a timer after the device is locked which will reboot the device is it isn’t unlocked successfully before the timer elapses. This is set to 18 hours by default but can be set between 10 minutes and 72 hours. It won’t chain reboot the device anymore.
All of our defenses against obtaining data from After First Unlock state devices are centered around auto-reboot. Our goal is preventing exploitation long enough for the device to cleanly reboot and get the data back at rest as if it had been obtained while it was powered off.
Due to the importance of auto-reboot, we recently reimplemented it as a low-level timer in the init process. This makes it much harder to prevent the device from rebooting. Previously, crashing system_server would restart the timer. It also allowed us to avoid it chain rebooting.
Our USB-C port control is set to “Charging-only when locked, except before first unlock” by default. New USB connections can only be made while unlocked, except BFU. After locking, new connections are blocked immediately and data lines are disabled when existing connections end.
We encourage users to use “Changing-only when locked” if they don’t need USB devices when the device boots or “Charging-only” if they don’t use USB beyond charging. There’s also an “Off” value disabling charging when OS is booted into the main OS boot mode for high threat models.
To clarify something that’s being misunderstood, neither of these 2 weaknesses are specific to Pixels. The mitigations they added are specific to Pixels. We aren’t aware of another Android device implementing the reset attack mitigation shipped by Pixels based on our proposal.
The specific vulnerabilities being exploited in fastboot mode are likely littlekernel USB vulnerabilities. If you look in the Pixel security bulletins, you can see many of the patches there are for components also used on other devices like the Samsung modem and littlekernel.
Thanks so much for all these details. I wouldn’t have seen the info otherwise.
I know this is not technically the right place to mention, but why not whitelist a USB connection like whatever the equivalent to a /udev rule is in Android? It certainly doesn’t bother me to unlock my device, to then plug in USBC headphones if that is the easiest setup and interface for users.
The use case I am thinking of is while riding a bicycle. I’ve ripped my helmet off in a hurry many times to avoid a bee sting. Stuff like that tends to unplug headphones. Or like comminuting home as it gets dark and I throw on a jacket and need to unplug and get situated. I’ll have to unplug with half damp gloves. I’m probably not going to get it unlocked without taking off my glove. Again, it is no big deal. It would be nice though if there was an advance option to whitelist a specific vendor ID and device ID, either by entering it manually or a more streamlined way of capturing the info after the device has been mounted.
Thanks for all the work you folks do!
The physical USB data lines are disabled by the OS’s current USB management, this is done as USB device ID’s can be spoofed, which opens up a security whole.