• Announcements
  • News regarding vulnerabilities reported to Google and physical attack roadmap

Twitter / X: https://twitter.com/GrapheneOS/status/1765871059830525978
Mastodon: https://grapheneos.social/@GrapheneOS/112056846851452393
Bluesky: https://bsky.app/profile/grapheneos.org/post/3kn5bmxgek32o


Thread quoted below for those who prefer reading it here:

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:

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 the 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.

    matchboxbananasynergy Google has awarded bounties of $5000, $3000 and $250 for our 3 vulnerability reports related to physical data extraction attack vectors.

    This is a great external validation of GrapheneOS as an elevated-security platform, and also as a contributor to increased security for all Android users.

    How does the "Charging-only when locked, except before first unlock" setting work?

      notnn

      1. Charging-only when locked, except before first unlock - this will likely become the new default. It means that the USB port will be fully functional when the device is in BFU, and when the device is unlocked. When the device is in AFU, but locked, it will only charge. If you plug in something while the device is in BFU or when unlocked, and then lock it, it doesn't kill that existing connection. This makes sense for most people as it has a very minimal impact on day-to-day use. If you use a keyboard and a USB hub for a screen on an 8th gen Pixel, for example, because connections work in BFU, you'll be good to go right away. When the device is unlocked, it makes sense for the port to be usable so you can plug stuff in. That said, the port being disabled except for just charging makes sense when it's in AFU but locked, in case someone takes the phone and tries to exploit it.

      https://discuss.grapheneos.org/d/11178-grapheneos-version-2024022800-released/12

        Congratulations to great work from the Graphene developers!

        Wow!

        Thanks to each and every one of you.

        Thanks for the detailed info update on the vulnerabilities around physical data extraction and the roadmap matchboxbananasynergy ! That sounds like really great and important features will be rolled out soon - thanks for your great work!

        matchboxbananasynergy

        You guys are killing it. I did notice some changes which I couldn't find further info on. Wondering if this is something thats changed from OS

        Seems like

        1) Existing wipe apps only kick from second user and doesnt actually delete/wipe anymore
        2) Wipes can't be interrupted to cancel anymore. While you can still go back to fastboot, up restarting device, it will revert back to Factory Reset/Erasing no matter how many times you reboot / power off

        One of my concerns with existing USB wipe was that data may still be in RAM. I know that may be the case if it is on owner profile and USB wipe triggers. Having a second profile that is locked/session ended would protect that data at least. My unknown was say you are on second profile, you have USB wipe active on Owner profile.
        You plug in and it goes straight to factory reset. Is there a chance here that the data / keys for the second profile are in RAM and therefore higher chance of being exploited when RAM Dumped since you were active on the second profile at the time of activation, even though the activation came from owner profile in the background?
        (I hope that made sense lol im not too technical)

          matchboxbananasynergy

          Awesome job team Graphene! If we could only get Google to work with us a little more on the certified OS stuff. That would be a dream and worth every bit of the bounties, IMHO.

          • N1b likes this.

          Protonuser

          1) Existing wipe apps only kick from second user and doesnt actually delete/wipe anymore

          Can you clarify what you mean?

          2) Wipes can't be interrupted to cancel anymore. While you can still go back to fastboot, up restarting device, it will revert back to Factory Reset/Erasing no matter how many times you reboot / power off

          You're still able to interrupt it by going to fastboot mode to either exploit fastboot mode or boot the OS to attempt to exploit it again. OS remembering that it's in the process of trying to wipe is not a real solution. The real solution is the OS wiping data without rebooting to recovery and shutting down after wiping is finished.

            matchboxbananasynergy passphrase primary unlock with fingerprint/PIN secondary factor for unlock!? That's fantastic! I use an 11 character passphrase now, this would be fantastic! I'm often putting it in after first boot because Private Lock keeps locking my phone, so I'm used to using it a lot, does this mean using it all the time, even after first boot? Then just using fingerprints for the second factor?

            I'd be so OK with that! If that were an option, I would use it all the time, it would round out the unlock mechanism with a very secure option for those of us who don't mind needing to take a whole 15 seconds to unlock instead of needing it done instantly....

            One thing that would help with this, if we could enable the microphone without unlocking the device? Right now, if the microphone is off for privacy reasons, and someone calls, it will ask "do you want to unblock the microphone?" And if you say Yes, you need to go through the whole unlock process. If you need to enter passphrase, + fingerprint/PIN, the call will have stopped ringing by then... So can you make "unblock microphone" via Quick Setting Tile like the Flashlight quick setting tile, in that it doesn't require unlock to activate please?

            Also, thanks for your incredibility awesome hard work on these new features! Really making GrapheneOS stand out from the crowd of other mobile OS's even more!

            Wish there was more I could do to show it but let it be known everyone on the graphene team are appreciated each day I turn on my phone.

            GrapheneOS

            I think you answered number 1 in another post, the apps seem to no longer work on secondary profiles, they will only end the session rather than wipe, which as you stated is most likely a compatability issue on their end.

            For the fastboot exploit, from what I am reading the next update from Google should fix this correct? Basing this off the below comment "resulting in the firmware's fastboot mode fully clearing all of the device's regular memory before enabling USB"

            Just wondering if you can shed some light on the final question.

            Scenario: USB Wipe is set up on owner profile. If you have ended second profile session, and fastboot is exploited, I would believe that second profile would be safe from RAM dump and only owner profile is compromised. Is this correct?

            Scenario 2: USB Wipe is set up on owner profile, and you are currently logged in to Secondary profile
            USB is plugged in and the device initiates wipe (Tested; I presume this is because owner is always active in the background?) If this occurs, will ram dump now also compromise secondary profile as it was logged in at the time of Factory Reset initiation?

            "We fully intend to make the same proposals to other Android OEMs like Samsung."

            What does this mean? They'll be working on a ROM for Samsung?

            • de0u replied to this.

              Dumdum
              Thank you for the clearest explanation of how this works that I have read to date.

              It should e labeled something like “USB port only for charging when in AFU and locked”

              Too many words, but I can’t figure out how to condense it.

                Blastoidea Thank you for the clearest explanation of how this works that I have read to date.

                The explanation was Matchbox's (quoted from the post in the link), not mine.