Google has awarded bounties of $5000, $3000 and $250 for our 3 vulnerability reports related to physical data extraction attack vectors. Both $5000 and $3000 issues are being exploited in the wild. $250 bounty is for a minor issue we found while doing general USB hardening work.
Most serious issue is the one with a $3000 bounty. We provided proof of in the wild exploitation and a proposal for preventing exploiting the class of vulnerabilities which is being implemented. For the one they're awarding $5000, we weren't sure they'd even consider it a bug.
The most serious issue is likely only getting $3000 because we do not know the specific bug being exploited. It was classified a low quality report, not because we did a bad job but because we don't have that info. We did provide a way to prevent getting data by exploiting it.
Our proposal for preventing getting data by exploiting the main issue should ship as a Pixel firmware update next month and the feature will become one of our baseline hardware requirements. It's already harder to use it with GrapheneOS and we've made major recent improvements.
Our recent improvements:
-
New USB-C port control setting integrated into the USB-C controller driver to disable USB at a hardware level. It will become "Charging-only when locked, except before first unlock" by default" soon. Shipped in 2024022600: https://grapheneos.org/releases#2024022600
-
We reimplemented our auto-reboot feature with a more hardened implementation which can't be bypassed by crashing system processes. This starts a timer when the device is locked which reboots unless it's successfully unlocked first. Shipped in 2024011300: https://grapheneos.org/releases#2024011300
-
We reduced the default auto-reboot timer from 72 hours to 18 hours. This also shipped in 2024011300. 18 hours is enough that users don't encounter it in practice as long as they unlock their phone a couple times per day. Users who need max security can use 10 minutes.
-
We run a full compacting garbage collection in SystemUI and system_server when the device is locked. Android already does this after unlock to clear credentials. Goes well with our kernel zero-on-free since it zeroes the data. Shipped in 2024020500: https://grapheneos.org/releases#2024020500.
Our main proposal should ship for the Pixel firmware in April, resulting in the firmware's fastboot mode fully clearing all of the device's regular memory before enabling USB. We could implement the same thing for the OS to make sure there's no data left from an unclean reboot.
Forensic companies keep misrepresenting adding support for extracting data from GrapheneOS via ADB based on a user providing lock method as being something more in their marketing. This is start of our response. We'll be pushing for much bigger changes for Android and Pixels.
We fully intend to make the same proposals to other Android OEMs like Samsung. We're starting with Pixels because they're the devices we use due to their high level of security. We're also going to begin advocating for big changes like encrypted memory and funding PoC attacks.
We've been working on a duress PIN/password feature for a while that's nearly ready to ship. It's taking so long because we had to prevent bypasses impacting existing panic / duress wipe apps and OS features. We also decided to do the USB-C control and auto-reboot features first.
Since 2016, we've planned to support adding a PIN as a 2nd factor for fingerprint unlock. A new contributor has started working on this feature. We'll get it done after duress PIN/password. This will allow using passphrase primary unlock with fingerprint+PIN secondary unlock.