Ride & Smile on Nostr: Link: https://x.com/GrapheneOS/status/1745506661467299946 Nitter: ...
Link: https://x.com/GrapheneOS/status/1745506661467299946
Nitter: https://nitter.net/GrapheneOS/status/1745506661467299946?s=20
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.
Donations to GrapheneOS fund the project. Support now to help fund and pay developers and help improve the mobile security landscape for everyone.
Nitter: https://nitter.net/GrapheneOS/status/1745506661467299946?s=20
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.
Donations to GrapheneOS fund the project. Support now to help fund and pay developers and help improve the mobile security landscape for everyone.