GrapheneOS: Frequent Android auto-reboots block firmware exploits

The GrapheneOS team behind the privacy and security-focused Android-based operating system with the same name is suggesting that Android should introduce an auto-reboot feature to make exploitation of firmware flaws more difficult.

The project revealed that it recently reported firmware vulnerabilities impacting Android devices such as Google Pixel and Samsung Galaxy phones, which could be exploited to steal data and spy on users when the device is not at rest.

When a device is “at rest,” it means that it is either turned off or has not been unlocked after booting up. In this state, privacy protections are very high and the mobile device is not fully functional because encryption keys are still not available for installed apps to use.

The first unlock after a reboot causes multiple cryptographic keys to move to the quick access memory so installed apps to work properly and the device switches to a "not at rest" state.

The GrapheneOS team highlights that locking the screen after using the device does not place it back into the "at rest" state because some security exemptions persist.

Rebooting the device terminates all temporary states, processes, or activities that could be exploited and requires authentication like PIN, password, or biometric verification to unlock, thereby re-engaging all security mechanisms.

Although GrapheneOS devs have not shared many details about the exploited firmware bugs, they proposed a generic mitigation that would work well in most cases: an auto-reboot feature that is already present in their operating system.

The idea is to minimize the window of opportunity for attackers and disrupt existing compromises by resetting all protection systems on the device more frequently than a user would.

GrapheneOS' auto-reboot system resets the device every 72 hours but as the OS maker comments, this is too long a period and they plan to reduce it.

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.

The developers touch on the topic of PIN/password security and its relation to the device’s encryption and security systems, as these authentication methods are used as keys to encrypt device data.

Secure element throttling is vital for securing short PINs and passphrases against stealthy brute forcing that could unlock not just the screen but also the secure enclave on the device’s chip.

BleepingComputer has reached out to the GrapheneOS team and Google to learn more about the discovered vulnerabilities, their impact, and observed exploitation cases. We did not receive a reply from GrapheneOS but Google provided the following statement:

Frequently rebooting your Android or iOS device has been touted as a good idea for fixing problems such as heating, memory, or even call signal but also. From a security perspective, this action can protect from illegal data recovery or mobile threats that do not have effective persistence mechanisms.

---

Update 1/15 - A GrapheneOS spokesperson has reached out to clarify a few points, and we have updated the article to reflect those.

The spokesperson told BleepingComputer that GrapheneOS that it has released an update for the auto-reboot system yesterday, on January 14, 2024.

The team re-engineered the auto-reboot function's implementation, moving it from the system_server to the init process for increased robustness.

The auto-reboot timer since the last unlock (not since last boot) has now been shortened to 18 hours (from 72 hours).

The spokesperson further explained that while unable to directly fix firmware bugs due to hardware limitations, GrapheneOS proposed firmware memory erasure on reboots and suggests improvements to the device administration API for more secure device wipes.