The heroes we need but dont deserve.
Vulnerabilities exploited in the wild fixed based on GrapheneOS reports
- Edited
A follow up:
Twitter / X: https://twitter.com/GrapheneOS/status/1775619234204197234
Mastodon: https://grapheneos.social/@GrapheneOS/112209146491225997
Bluesky: https://bsky.app/profile/grapheneos.org/post/3kpavxfn2yi2c
Reset attack mitigation for firmware-based boot modes such as fastboot mode has been added as one of our requirements for GrapheneOS support:
https://grapheneos.org/faq#future-devices
It shipped as part of this month's firmware updates for Pixels based on our proposal. Other OEMs should add it.
See our thread at https://grapheneos.social/@GrapheneOS/112204428984003954 for more details. It was added to prevent extracting data via fastboot mode vulnerabilities exploited in the wild. There are now 3 features on our list of hardware requirements where we played a major role in getting them added to Pixels.
- Edited
@TrustExecutor Your reply has been removed for posting links to misinformation from a highly malicious account spreading massive amounts of misinformation about GrapheneOS for years as part of promoting a proprietary product. As usual, their claims are highly inaccurate. One of these two vulnerabilities mainly refers to the lack of an exploit mitigation which is now deployed for Pixels but not elsewhere. The other refers to an app vulnerability caused by AOSP not implementing support for wipe-without-reboot. Pixels partially worked around the 2nd issue in firmware but a proper solution will require both AOSP to support wipe-without-reboot which they're working on implementing. Please don't link to content from this malicious account. We cannot reply on Reddit because they've blocked the project account, developer accounts, moderator accounts, etc. which on Reddit prevents participating in any thread they create including not just their posts but the thread from a comment. Someone they've blocked can't even reply to someone who replies to their comment, and they use this as a weapon to spread misinformation.
@TrustExecutor Their claims about auto-reboot and disabling reboot on the lockscreen are also completely wrong. A clean reboot on GrapheneOS is a good thing due to zero-on-free. A clean reboot or shutdown kills the processes which frees the slab and page memory tied to them, resulting in it being zeroed. That's how GrapheneOS defended against attacks via firmware boot modes. It isn't adequate because an attacker can trigger a reboot in another way. Shutting down the device also doesn't magically clear all the memory but rather it starts degrading once it's no longer powered. The reason we cared so much about having the firmware perform reset attack mitigation is because an attacker can trigger a hard reset by opening up the phone and causing any kind of fault which triggers it to crash and reboot. If they press reboot in the OS, they're helping by zeroing the data via a clean reboot. Disabling rebooting while locked wouldn't help anything and the whole point of auto-reboot is to do that automatically after a timer expires to get the memory zeroed. The person you're linking to doesn't understand security but pretends as if they do and spreads massive amounts of misinformation about it.
GrapheneOS Thanks for your educational reply. This is what I first suspected, a inferior competing OS spreading a bad narrative about GrapheneOS. I will stop linking to what I suspect is misinformation.
And he is obviously pushing the "government backdoor in Pixels" narrative, at the same time ignoring the lack of field reports of those backdoors being used. The fact that the forensic companies has to revert to using an exploit is quite telling of the Pixel's security. The swedish police had an investigation where they could not extract data from a Pixel running GrapheneOS, and I bet they have access to all the latest and most exotic forensic tech.
TrustExecutor If you look into it, it's a proprietary OS based on Android 11 LineageOS with incomplete Android privacy/security patches. It's made for insecure OnePlus devices. They're trying to get money by convincing people that's worth buying from them. They're heavily invested in peddling misinformation about GrapheneOS, DivestOS, Android, Pixels and other things. It appears motivated by more than simply selling a few people their scam OS.
- Edited
GrapheneOS The developer you're talking about's only argument is "trust me bro" and his scam could well be used for malicious purposes, its developer effectively spreads misinformation about GrapheneOS, Pixel etc.
TrustExecutor The swedish police had an investigation where they could not extract data from a Pixel running GrapheneOS
Could you provide a link for this?
GrapheneOS hi there what do you mean by a "clean reboot"
Is this pressing "restart" from the power menu?
Auto reboot timer ?
What about "power off" option from the power menu?
Am I guessing that a NON clean reboot is when the system crashes and reboots, but it takes alot shorter time to start?
Is this pressing "restart" from the power menu?
Any regular reboot triggered by the OS. Restart in the power menu, auto-reboot, idle reboot after update if enabled in the update client, reboot triggered by a device admin app, etc.
Am I guessing that a NON clean reboot is when the system crashes and reboots, but it takes alot shorter time to start?
You're referring to system_server crashing, which respawns system_server and other system processes. That's not really a reboot at all, although it's often called a soft reboot. It's not what is being referred to by an unclean reboot. An unclean reboot would be a hardware/firmware/software fault causing a hard reset without the OS cleanly shutting things down.
GrapheneOS thank you for this reply, I appreciate your help.
Can I ask, probably a stupid question.
If you power off the phone, does that have the same effect as restarting , or is there more risk with a power off
L8437 The advantage of the phone being powered off is that the memory will rapidly begin to degrade. The advantage of the phone being rebooted is that the firmware or OS can zero the memory explicitly. Aside from improved usability, another reason we prefer to reboot is because we're going to be doing explicit zeroing of all memory at boot for the OS similar to how fastboot mode now does it based on our proposal. This provides an opportunity to zero anything not already zeroed as part of our zero-on-free implementation which zeroes the freed allocations and freed pages as part of the process of ending the OS running.