Exploit of device after first unlock to obtain data that isn't at rest
https://github.com/GrapheneOS/kernel_common-5.15/commit/b1cd3dba068ac6cd5535fa852ea93f8fd56e70fb is a significant difference between GrapheneOS and the stock OS in this area. On a regular reboot, the kernel actively clears the memory which was used by the OS. This won't happen on kernel crashes, emergency reboot from overheating or hardware triggered reboot.
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.
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.
- Edited
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.
GrapheneOS Thank you once again for your replies to myself and the others in this thread with a great amount of detail, that are also very understandable and logical. You've increased my knowledge and awareness of a few things here.
And thank you for filing an issue on this also and once again improving our security and privacy in so many ways. Looking forward to the duress feature once you're happy it's ready to be released
GrapheneOS Does this mean that if the phone has been unlocked (not BFU) and they click reset (or wasted triggers) and then they hold volume down, that fast boot would still be AFU and not secure?
Where does the Auto-Reboot function work? If the device is in fastboot mode, I presume the auto reboot would not work? ie they can leave it in the fastboot mode AFU
Hathaway_Noa hey, is there any ways to contact you?
GrapheneOS Thanks for all the efforts and hard work!
krayo If you post your email or something I can contact you, I will do that.
One more reason to use molly with unified push and generic notifications with locked db.
Hathaway_Noa where can I read up more about it
Hathaway_Noa do you use matrix?
@kray69:matrix.org otherwise can give something else
Check your DM on matrix
Hey @Hathaway_Noa can you contact me as well?
@tempuser9870:matrix.org
I was always under impression that AFU + physical access is game over given a determined adversary. Was I wrong?
- Edited
Hathaway_Noa 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.
It's weird that they are able to brute force the password like that because of 2 reasons:
A flagship device with an SE also comes with a hardware inline crypto engine (ICE) that stores data encryption keys during the runtime of the OS. So they may see plain text data in the RAM dump but seeing keys in memory goes against the the purpose of having an ICE.
Let's assume they can see sub-keys in memory dump. But this alone is not enough to brute force the credentials. It is because they need to decrypt the Synthetic Password first which is only possible with the active cooperation of Weaver and Strongbox Keymaster.
I think the Synthetic Password is being kept in plain-text in the memory dump which I think is accidental because once its participation to decrypt CE keys completes during BFU to AFU state transition, it's no longer required by the LockSettingsService so it should be released from the memory.