Rollback is disabled before it updates the anti-rollback counter.
Conversation
It still hurts custom rom users. I already don't care about my safetynet state, why should I be locked to an android 13 bootloader for security issues that I choose to not care about?
1
3
Rollback protection is part of verified boot. It has existed for the SoC boot chain, secure element and the OS itself for many years. Pixels have used it for the OS and secure element for years. It wasn't used in practice for SoC boot chain due to being a development annoyance.
1
2
An important security feature not being fully implemented due to it being a development annoyance is problematic. GrapheneOS is an aftermarket OS focused on Pixels and we wanted this feature to start being used properly and complained about it not being done on the past devices.
2
1
Not everyone using an aftermarket OS wants to roll back the security model and disable security features. Proper verified boot is a small part of what we expect potential hardware partners to implement. It's not proper verified boot if firmware bypasses aren't fixed like this.
1
You're welcome to use something other than GrapheneOS if you don't want the standard security model and hardware-based security features intact. Rollback protection is a basic security feature and has already been used for years, just not for the early SoC boot chain in practice.
2
And ultimately, that's why I don't use GrapheneOS.
But it could be a great OS if it didn't insist on denying owners control of their devices, so it's a shame.
It's looking like this case wasn't even a security fix, just DRM.
1
Verified boot is an important security feature primarily used to make privileged persistence much more difficult for an attacker. If they can simply write out a vulnerable SoC boot chain, it doesn't work. It's secondarily used for anti-tampering and the same thing applies to it.
2
Yes, but my security model (for my phone) assumes I always have physical custody of my phone, so verified boot is worthless to me.
I understand and agree it is important to others.
I'm not suggesting taking any of that away from them.
2
1
The primary threat model for verified boot is defending against a remote attacker trying to persist on the device, not physical security. Anti-tampering is a secondary and less important threat model for verified boot. Chromebooks don't really bother even trying to do that part.
Verified boot on ChromeOS is entirely for defending against remote attackers. Verified boot on Android is primarily for that but also tries to make tampering much harder, although it's a different kind of thing than the remote threat model it defends against.
1
The primary threat model is an attacker uses an exploit chain to get temporary control over the OS. They use a Linux kernel exploit and own the kernel, etc. Due to verified boot, their persistence is gone after a factory reset unless they have working verified boot exploits too.
2
Show replies
If the owner could re-flash the entire device, it wouldn't be possible for a remote attacker to persist in the first place...?
1
You flash device by interacting with firmware on the device and there are a whole bunch of components which have firmware: SoC firmware including firmware for GPU, media encode/decode, image processing, crypto engine, TEE and much more, touchscreen, battery, USB controller, etc.
2
Show replies
What remote attack could get access to a bootloader? Even with an unlocked device, how is that a threat?
1
I suppose if they can compromise the kernel, they could start flashing the bootloader storage too...
1
Show replies