• General
  • Exploit of device after first unlock to obtain data that isn't at rest

GrapheneOS That's interesting, I had never considered there are emergency reboots that are different to regular ones. Could things like holding down power + volume be considered as such? I assume they're more along the lines of 'pulling the plug' so to speak, whereas a regular reboot actually does 'clean up after itself'. If those metaphors work anyway.

Very good info, thanks as always! Good to know your looking into disabling the emergency reboots as well

    final Thank you for a very detailed and understandable answer to my questions, really appreciate it. I suspected it would be somewhat similar to how you explained but it's very nice to have it properly answered in a concise and comprehensible way. Thanks again!

    roamer4223 so to that point, couldn't wasted be adapted to do a real reboot and real wipe in that case? Wouldnt this be pretty easy?

      missing-root
      Personally, not sure about that. Though on the same lines I do believe GrapheneOS is working on a duress feature that will erase your device after entering a specific pin code, if I am not mistaken.

      I see that 'Wasted' has more features from a glance at their Github. Though looking at it - I would be extremely hesitant to use it myself, even if that part of it was implemented correctly, as it uses some very dangerous permissions that could end up possibly increasing your attack surface I would imagine. To be fair I did only have a very quick look so I may be wrong.

        ahh I just saw @final mentioned this duress feature GOS is working on earlier in this thread.

        Also wasn't saying anything against the devs of 'Wasted', I'm sure they know more than me. Personally though, I will wait for the Graphene team to implement their duress feature

        roamer4223

        Could things like holding down power + volume be considered as such.

        No. There are emergency reboots for situations like overheating. A kernel panic is also a different code path to a clean reboot but not the same as an explicit emergency warm reboot.

        missing-root Wasted is using the device management API to trigger a factory reset via rebooting into recovery. This is inherently insecure because you can hold volume down to reboot to fastboot mode instead. It's inherently insecure and we're always told people that these panic/duress apps don't work correctly...

        roamer4223 Our experimental duress feature works properly because it wipes data without requiring a reboot to recovery. It could also be exposed as optional a panic button. The existing implementations of these features elsewhere are known to not work properly since they require rebooting to recovery for a normal factory reset which was never intended to be used in this way.

        final Being able to RAM dump from fastboot mode is guarded by a check for the device being unlocked. If they're able to do it without being unlocked, that's an exploit, even if it's a trivial one. If the flaw being used in fastboot mode was known, it would be fixed in a firmware update.

        There shouldn't be relevant data left in memory after a normal reboot to fastboot mode, but data can persist through reboot from a kernel crash or similar situations. Overheating is also known to trigger an emergency reboot.

          @final

          Yes, providing the user authenticated once, which keeps the secrets in memory.

          Secondary users can be put back at rest. For both the main user and secondary users, encryption keys aren't available to the OS after unlock but they are in non-OS memory.

            Hathaway_Noa

            bypassing the secure element.

            they start bruteforcing the password of the device bypassing the secure element of the pixel device (titan m)

            They can bypass secure element by booting into the fastboot mode when the phone has been previously in AFU, after that they dump the RAM since the RAM hasn't been cleared yet and bruteforce the keys giving them a password.

            They aren't bypassing or exploiting the secure element. The device wasn't at rest so the keys were usable by the OS. They're brute forcing against what's still in memory to get the password.

              GrapheneOS changed the title to Exploit of device after first unlock .
              GrapheneOS changed the title to Exploit of device after first unlock to obtain data that isn't at rest .

              GrapheneOS Being able to RAM dump from fastboot mode is guarded by a check for the device being unlocked. If they're able to do it without being unlocked, that's an exploit, even if it's a trivial one. If the flaw being used in fastboot mode was known, it would be fixed in a firmware update.

              Wow, I am quite surprised about that detail then, that's pretty concerning. The video itself simply skips to the RAM dump being accomplished, so that does alert my concerns a little. I'm guessing a fix for this would be beyond the project's reach since its a firmware issue? This is not counting the measures you've mentioned on this thread prior of course.

              GrapheneOS Secondary users can be put back at rest. For both the main user and secondary users, encryption keys aren't available to the OS after unlock but they are in non-OS memory.

              Thanks for the added details, I forgot to mention this. Your team's added responses are always appreciated.

                final

                Wow, I am quite surprised about that detail then, that's pretty concerning. The video itself simply skips to the RAM dump being accomplished, so that does alert my concerns a little. I'm guessing a fix for this would be beyond the project's reach since its a firmware issue? This is not counting the measures you've mentioned on this thread prior of course.

                They're doing some kind of exploit to be able to dump the RAM. It may be a trivial vulnerability. We've previously seen a fastboot vulnerability being used to dump RAM before this. It's not quite the same for GrapheneOS due to it wiping memory as soon as it's freed for the kernel page allocator, kernel slab allocator and main userspace allocator (malloc). This means much less sensitive data is kept around in memory. On a normal reboot, most data in wiped from memory as part of ending all the processes, etc. It would be possible for the firmware to do a more complete job and that would ideally be supported.

                We can file an issue about the fastboot vulnerability and also about implementing firmware-based reset attack mitigation through clearing the memory on reboot more reliably than the OS can take care of it.

                  We've reported a vulnerability about missing reset attack mitigation explaining how fastboot mode is being exploited.

                  Reference Info: 318411468 Tensor Pixel fastboot mode vulnerability being exploited by forensic companies due to lack of reset attack mitigation

                  It's entirely possible to fix this whole class of problem via reset attack mitigation by clearing all the memory on reset while locked. It might as well also be cleared when shutting down. We've also brought up the fastboot mode vulnerability that's being exploited but we don't know the details of it. That vulnerability wouldn't be serious if there was reset attack mitigation. It could be used to flash another verified boot, enable debugging features, etc. As a side note, we also mentioned that the device management factory reset API is being used by apps in an insecure way where they expect that it can't be stopped once it's started even though an attacker can just interrupt it. We've always known this and therefore our work on a duress password feature and panic feature has focused on implementing a way to wipe without a reboot to recovery, which is why it's taking so long to perfect it and ship the features.

                    • [deleted]

                    GrapheneOS Yes please file such an issue. THX.

                      [deleted] We've reported it already and expect it to be resolved quickly due to active exploitation of the lack of reset attack mitigation (firmware zeroing memory on reset/shutdown). The fastboot mode vulnerability may be hard to find but they'll likely dedicate some resources to it. Fixing the fastboot mode vulnerability isn't very important if they add reset attack mitigation.