Our current affair about #GrapheneOS automatic reboot and our project's disclosed vulnerabilities on Fastboot firmware to Google has reached some media outlets.
It appears BleepingComputer received a statement from Google confirming the reported issues and will be taking steps to review it.
The GrapheneOS project once again is leading the forefront of mobile security research.
It should be worth noting however, that the automatic reboot is not the fix for these vulnerabilities we are suggesting. We suggested a reset attack protection mechanism by forcing RAM to be cleared after an unsafe reboot or during Fastboot.
The article could have put more focus into that component, but this publicity is good publicity.
That's amazing. Thank you for what you do!!
Hell ya. Hey - if im running graphene on a pixel 4a, do i need to stop delaying and upgrade asap ? 🤙
We strongly suggest upgrading to a new device as they become unsupported. This is because you can't get firmware upgrades by the OEM and therefore miss patches. We keep devices supported until the next OS version for harm reduction so users have time and comfort intended to upgrade. Pixel 6a is the cheapest supported option, but Pixel 8 and above have the best security thanks to hardware memory tagging support.
In the case of the recent exploit, this exploited firmware. Even if the OS provided a countermeasure - it would never be fixed on the firmware side for an older device. These companies also trivially talk about breaking into these older, unsupported devices easily. Even if a fix came for a 4a, you have no guarantee for the next.
If for whatever reason you can't upgrade device, DivestOS is a good choice for that once GrapheneOS stops updating.
Please expand on this:
GrapheneOS also notes that flight modes on smartphones that people assume reduce the attack surface often still allow data exchange via Wi-Fi, Bluetooth, NFC, and USB Ethernet, so depending on the attack vector, it may not be an effective protection measure.
Yes, the project affirms these statements.
Aeroplane modes are designed to turn off the cellular radio - they are a benefit for avoiding communication with the cellular network, however, you can still do network connections in other ways such as WiFi even with Aeroplane mode on.
You shouldn't just rely on a single option. It's up to the user to connect to networks that they trust, the services they trust and use features GrapheneOS already provides in regards to that.
GrapheneOS provides features to disable Wi-Fi and Bluetooth to after a set time of no connections, disabling new USB accessories when locked, and more. The OS reduces attack surface in several components.
If a user needed to use the cellular network, there is also an LTE only mode to reduce attack surface by not using legacy 2G/3G code and bleeding edge 5G code.
We have posted some clarifications regarding the BleepingComputer article on Twitter in response to some Android security experts who have criticisms on how the article is read out. The reporting is not as accurate as it should be. While the article is positive there are still some mistakes.
The mitigation the project is suggesting is a reset attack protection where memory is zeroed to help prevent ramdumps from being taken advantage of in these scenarios. The article suggests the positive use of a auto reboot function, however it reads out like it is our solution to the exploit -- it is not. This is not a primary mitigation, rather a simple countermeasure.
Twitter: https://x.com/GrapheneOS/status/1746585083279028276?s=20
Nitter: https://nitter.cz/GrapheneOS/status/1746585083279028276?s=20
Thank you for your service 🙏
