• Announcements
  • Improvements to factory resets by Google due to reports by GrapheneOS

Twitter /X: https://twitter.com/GrapheneOS/status/1772616917611585809
Mastodon: https://grapheneos.social/@GrapheneOS/112162304896898942
Bluesky: https://bsky.app/profile/grapheneos.org/post/3kom4cotcxr24


Google is publicly working on a fix for the factory reset vulnerability we reported:

https://android-review.googlesource.com/c/platform/frameworks/base/+/3008138

Currently, apps using device admin API to wipe do not provide any security against a local attacker since you can interrupt them. Forensic companies are aware of this.

We weren't sure if they would even consider this to be a valid vulnerability but it was accepted as a High severity issue with a $5000 bounty. We also reported what we consider a far more serious firmware vulnerability which received a $3000 bounty due to not having full info.

They're going to be shipping the mitigation we proposed for preventing obtaining data via exploiting vulnerabilities in firmware boot modes in the April security update. We also proposed software improvements which may ship soon. We aren't sure when factory reset will be fixed.

GrapheneOS provides substantial defenses against obtaining data from devices in the After First Unlock state. We recently made major improvements in this area including our new USB-C port control feature able to disable data lines at a hardware level, unlike the standard feature.

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.

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.

Our main defenses against this are our standard exploit protection features:

https://grapheneos.org/features#exploit-protection

Wiping freed memory in kernel/userspace also helps beyond exploit mitigation. We also added full compacting GC for core processes when locking and we're working on much more.

We've planned to support adding a PIN as a 2nd factor for fingerprint unlock since 2016. A new contributor has recently made a lot of progress on it. We'll get it done after duress PIN/password. It will allow using passphrase primary unlock with fingerprint+PIN secondary unlock.

    matchboxbananasynergy I don't quite understand the reasoning for one thing from a security perspective, perhaps you can educate me...

    Why is the default "charging only when locked except before first unlock"? Doesn't this default have the major downside of, after an auto reboot to secure the device after it is in the hands of an adversary, it has just re-enabled the data lines of the USB and made the device much easier to access?

    From a security perspective, wouldn't " charging only after locked" be more reasonable as a default? Then, if people really need USB functionality before first unlock (really, I've tried and I'm hard pressed to think of any reason why this would even he needed), then they would flip it to this setting themselves. It seems to me that the current default leaves many users who don't need this specific functionality open to potential attack, while catering to the few who might need this USB port policy. Many users aren't going to change the default, after all, so secure defaults are, as always, important...

    Love the idea of a second PIN/fingerprint also! That reminds me of how I secure my Proton account, there it is password -> 2FA -> second mailbox password. Adds just a but more security. If the second password could also fire the duress function, that would be so amazing!

      Tryptamine

      Why is the default "charging only when locked except before first unlock"? Doesn't this default have the major downside of, after an auto reboot to secure the device after it is in the hands of an adversary, it has just re-enabled the data lines of the USB and made the device much easier to access?

      The main purpose of the feature is defending the encrypted data that's not at rest due to being in the After First Unlock state.

      An attacker can reboot the device themselves. This isn't enabled in any way by auto-reboot. USB data lines are also active in other boot modes including the firmware fastboot mode, OS recovery mode, OS fastbootd mode and OS charging mode. An attacker can still turn off or reboot the device if that was disallowed by the OS while locked, so it doesn't make sense to implement the proposal some people have to disable it.

      The default value of the feature avoids breaking anything for end users since they can still use a desktop setup with a USB mouse, keyboard, monitor, etc. along with still being able to unlock a device with a broken touchscreen.

      A sophisticated attacker is going to gain control of the device given enough time. Auto-reboot is to get the data back at rest and the USB-C port control feature is mainly there to help with defending the device until that happens. They can also simply boot into an alternate mode (fastboot, fastbootd, charging, recovery).

        GrapheneOS Thank you for the explanation! It does make perfect sense now, of course an attacker could boot into an alternative boot mode, and just use that boot mode to gain access to the USB. It also makes sense to protect the encrypted data that is not at rest, that is the really important thing here...

        Also I was hoping you would give some explanations of potential reasons for having functionality for USB devices having access before first unlock, and you have, thanks for that! Again, makes sense to be able to use a phone with broken touchscreen or a USB mouse and keyboard. Of course it's best to avoid causing issues for users, since GrapheneOS has quite a wide user base.

        Thanks for the concise explanation!

        5 days later