GrapheneOSGoogle 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:
1) 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.
2) We reimplemented our auto-reboot feature with a more hardened implemention 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.
3) 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.
4) 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.
idkrn@GrapheneOS would the team consider adding a timeout for biometrics? After a certain amount of time, biometrics would no longer be used as a single unlock mechanism
Network is reliable@idkrn @GrapheneOS I upvote this too
@GrapheneOS Can you explain a bit about preventing bypasses from impacting existing features?
@moonbolt Existing implementations of duress and panic features use the standard Android device administration API to wipe the device. This is the only way for an app to do it, but is also how OS implementations work in practice. This API wipes the device by rebooting to recovery to perform a factory reset. An attacker with possession of the device can stop it rebooting into recovery. There are instructional videos for law enforcement covering this and forensic products doing it automatically.
@moonbolt Google was willing to consider this a valid vulnerability in our report to them about it despite the device admin API not really being designed with these use cases in mind. It's easy to replicate yourself.
We have a backlog of other vulnerabilities we need to report to them and we'll try to find time for it. The bounties they paid for this help to fund the time needed to report issues to them which is otherwise hard to justify rather than working on more GrapheneOS improvements.