Vulnerabilities exploited in the wild fixed based on GrapheneOS reports

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

The options and their meanings:

1. On - This means the USB-C port is on, like it would be on Stock OS. No restrictions.

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

3. Charging-only when locked - This is similar to the above, but the difference is that here, the port only charges in BFU as well, which means less attack surface when the device is in BFU, but the tradeoff is that you cannot connect a keyboard etc. for the first unlock.

4. Charging-only - this one should be self explanatory, but just in case it isn't, this means that no matter if the phone is in BFU or AFU, locked or unlocked, the port can only be used for charging. It's important to keep in mind here that if someone gets access to the device while it's unlocked, they can simply change the option in security settings to "on" etc.

5. Off - as mentioned before, this is the most aggresive option, disabling the port entirely in the OS but allowing you to charge when the phone is powered off.

[deleted] fantastic! Thanks for the explanation.

Because of this, I was able to change my owner pin to using a password....but where i manually enter characters + press yubikey to add extra characters

If this makes sense

Thanks for your efforts

The heroes we need but dont deserve.

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

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?

L8437

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.