pull down to refresh

Overview

The team and users at GrapheneOS have uncovered a vulnerability in smartphones being actively used by digital forensics companies / exploit brokers to facilitate extractions in the after-first unlock (AFU) phase.
Because of how the vuln is discovered, there is no knowledge of a GrapheneOS user affected.
If you are taking advantage of the security features GrapheneOS provides, such as a low automatic reboot time, user profiles, or strong brute-force resistant passwords (like 7-8 diceware words) then you have nothing to worry about.

Details

The exploit discovered is an exploit in the fastboot firmware, which (with methods not known) allows the threat actor to bypass requirements needed to perform a RAM dump on the device. This RAM dump was facilitated by the help of an emergency/unsafe reboot, which does not zero (erase) the RAM safely. An example of an unsafe reboot is a reboot caused by a device admin with remote erasure access or duress app.
With this RAM dump, a threat actor can brute force a device as key contents remain in memory when a disk encrypted device is captured while in an AFU state. By imaging the memory of any device performing encryption while in use and unlocked, it is possible to completely avoid the secure element's protections because of the key contents in memory they are able to brute force.
Magnet (GrayKey) and MSAB (XRY) are two companies known to attempt GrapheneOS support on their products. Proof of an exploit was uncovered by a public video promoting a bypass for an unreliable device erasure app (Wasted), which is now removed off of all relevant social media after discovery by users of that app and GrapheneOS on forums and GitHub repositories. The video has been provided as proof to Google which is now being evaluated as a high-severity vulnerability.

Role of GrapheneOS

GrapheneOS already provides hardening and security features designed for the user to take advantage of. Automatic reboot allows the device to reboot after a set amount of time of inactivity, and the improved user profiles allows you to end the session of profiles, removing their encryption keys from memory and back to the secure element. This helps put the profiles and the device back to a BFU state, leaving them unaffected to these types of exploitation.
GrapheneOS' hardened malloc provides several benefits in regards to this scenario, by zeroing data when freed for kernel and malloc. While this is designed to mitigate uninitialized data usage vulnerabilities, this reduces the amount of artefacts in memory a person could analyze.
In addition, GrapheneOS is close to providing a real duress erasure feature, not based on insecure, bypassable (long known) implementations caused by duress apps like Wasted. This will be delivered soon.

Further fixes

A reset-attack protection mitigation suggestion has been provided to the upstream to protect Fastboot being used to exploit ramdumps in the future. It's also been suggested to bring fixes to prevent duress apps from having insecure emergency reboots.
GrapheneOS hopes Google fixes or adds a security mechanism in place to help Android users, not just GrapheneOS.
Great write-up 👏
reply
21 sats \ 0 replies \ @anon 13 Jan
I appreciate GrapheneOS very much! Thanks!
reply
solid.
reply
Commenting here since it's being reposted: This vulnerability affected the STOCK Android OS, not GrapheneOS. GrapheneOS only discovered the vulnerability and reported it. It had not been suggested the same capabilities work on GrapheneOS anywhere when these came out providing you didn't have garbage security setups either.
reply
reply
Great post
reply
continuing to justify my move to graphene
reply