CVE-2024-32896 which is marked as being actively exploited in the wild in the June 2024 Pixel Update Bulletin is the 2nd part of the fix for CVE-2024-29748 vulnerability we described here:
The latest Pixel security updates now contains boot chain firmware security improvements caused by our vulnerability reports to Google. The reporting developer who provided a PoC mitigation and the #GrapheneOS Foundation as a whole are now credited on the Android Security Acknowledgements.
https://source.android.com/docs/security/overview/acknowledgements#april-2024
The two vulnerabilities (now assigned as CVE-2024-29745 and CVE-2024-29748) were announced by us as being exploited in the wild, targeting a stock Pixel device. Exploitation were done by forensics companies who design (or more likely, buy) zero-day exploits to perform data extraction with physical access and sell them as a product to LE or state agencies. Companies in the business include Cellebrite, MSAB, Magnet (GrayKey) among others.
CVE-2024-29748 refers to a vulnerability providing the ability to interrupt a factory reset triggered by a device admin app, by holding volume down you are were able to cancel the reset caused by apps like Duress or Wasted. It appears they've implemented a partial solution in firmware.
CVE-2024-29745 refers to a vulnerability in the fastboot firmware used to support unlocking/flashing/locking. Forensic companies are rebooting devices in After First Unlock state into fastboot mode on Pixels and other devices to exploit vulnerabilities there and then dump memory.
Here is Google's confirmation of them: https://source.android.com/docs/security/bulletin/pixel/2024-04-01#Announcements
There is no knowledge of this affecting a GrapheneOS device because of the defences already in place, however since these discoveries we have placed additional focus in protecting data not at rest with security features like the USB controls, improving the auto-reboot feature and working on future features like no-reboot factory resets, a duress PIN/password and second factor device unlock.
A new GrapheneOS update is released now with the full security backports, rather than a partial release from them not being available yet.
None of this is actually Pixel specific.
Bulletin:
https://source.android.com/docs/security/overview/acknowledgements
Attribution to us:
https://source.android.com/docs/securi
CVE-2024-32896 and CVE-2024-29748 refer to the same vulnerability of interrupting reboot for wipes via the device admin API, which applies to all devices.
CVE-2024-32896 is a full fix in AOSP as part of Android 14 QPR3. It's not at all Pixel specific.
This is being widely incorrectly reported in tech news coverage. Pixel Update Bulletins are almost entirely patches for vulnerabilities which apply to other devices too. Android Security Bulletins are the list of what other OEMs are required to fix, not the full list of patches.
We explained this in our previous thread:
https://grapheneos.social/@GrapheneOS/112204437363495338
CVE-2024-29748 was a mitigation for the issue implemented in the Pixel bootloader. Full solution is implementing wipe-without-reboot, which is now a standard feature in Android 14 QPR3 released as part of AOSP.
Our 2024052100 release backported the upstream wipe-without-reboot feature being shipped in the June 2024 release of Android (Android 14 QPR3): https://grapheneos.org/releases#2024052100.
We extended it to make it more robust via extra redundancy in our 2024060400 release:
https://grapheneos.org/releases#2024060400.
There were 2 main issues:
1) memory not wiped when booting firmware-based fastboot mode, allowing exploiting it to get previous OS memory
2) AOSP device admin API depends on reboot-to-recovery to wipe before Android 14 QPR3
Neither of these issue is being fixed outside Pixels yet.
Each month, Android has a new version released. These are the monthly, quarterly (QPR) and yearly releases. The baseline monthly security patches are NOT the monthly releases of Android. They're backports of a SUBSET of the patches with High/Critical severity, not all patches.
Most devices only ship the backported patches to older Android releases (12, 13 and 14). Pixels ship the monthly, quarterly and yearly releases. Other devices will mostly get the 2nd vulnerability fix when they update to Android 15. They'll have to fix the 1st issue on their own.
We have a thread about forensic company capabilities at:
#GrapheneOS uncovers leaked documentation for smartphone exploits by Cellebrite.
XRY and Cellebrite say they can do consent-based full filesystem extraction with iOS, Android and #GrapheneOS. It means they can extract data from the device once the user provides the lock method, which should always be expected. They unlock, enable developer options and use ADB.
Cellebrite's list of capabilities provided to customers in April 2024 shows they can successfully exploit every non-GrapheneOS Android device brand both BFU and AFU, but not GrapheneOS if patch level is past late 2022. It shows only Pixels stop brute force via the secure element.
Cellebrite has similar capabilities for iOS devices. This is also from April 2024. We can get the same information from newer months. In the future, we'll avoid sharing screenshots and will simply communicate it via text since to prevent easily tracking down the ongoing leaks.
Pixel 6 and later or the latest iPhones are the only devices where a random 6 digit PIN can't be brute forced in practice due to the secure element. Use a strong passphrase such as 6-8 diceware words for a user profile with data you need secured forever regardless of exploits.
Pixels are doing a bit better on the secure element front and iPhones are doing a bit better against OS exploitation, but not by much.
As always, this shows the importance of our auto-reboot feature which gets the data back at rest after a timer since the device was locked.
Our focus in this area is defending against exploitation long enough for auto-reboot to work. It's set to 18 hours since the device was locked by default, but users can set it as low as 10 minutes. Since around January, we massively improved security against these attacks.
By default, our recently added USB-C port control feature disallows new USB connections in AFU mode after the device is locked and fully disables USB data at a hardware level once there aren't active USB connections. Users can set it to also do this in BFU or even when unlocked.
Users with a high threat model can fully disable USB including USB-PD/charging while the OS is booted to only allow charging while powered off or booted into the fastboot/fastbootd/recovery/charging modes.
GrapheneOS on 8th gen Pixels is ideal due to hardware memory tagging.
Consent-based data extraction (FFS) is not in the scope of what we're trying to defend against beyond shipping our secure duress PIN/password implementation to replace insecure approaches via apps. Data users can backup is inherently obtainable with consent, which is nearly all.
Within the past 24 hours, there has been an attack on GrapheneOS across social media platforms misrepresenting consent-based data extraction as GrapheneOS being compromised/penetrated. The person doing it is pretending to be multiple people and falsely claiming we covered it up.
GrapheneOS is the only OS having success defending against these attacks. We could do more with a successful hardware partnership such as having encrypted memory with a per-boot key instead of relying on our kernel memory zeroing combined with auto-reboot and fastbootd zeroing.
New versions of iOS and Pixel OS often invalidate their existing exploits, but devices in AFU are stuck in AFU mode waiting for new exploits.
Random 6 digit PIN is only secure on a Pixel/iPhone and only due to secure element throttling. Use a strong passphrase to avoid this.
If you wonder why duress PIN/password is taking so long, it's because we aren't doing it for show like existing implementations. It needs to work properly and guarantee data will be unrecoverable with no way to interrupt it. Slowly rebooting to recovery to wipe isn't acceptable.
See https://x.com/GrapheneOS/status/1775305179581018286 for our thread covering the firmware improvements we helped get implemented in the April 2024 release for Pixels. It doesn't currently really help the stock Pixel OS because they haven't blocked the OS exploits that are being used yet but it helps us.
Our hope is that our upcoming 2-factor fingerprint unlock feature combined with a UI for random passphrase and PIN generation will encourage most users to use a 6-8 diceware word passphrase for primary unlock and fingerprint + random 6-digit PIN for convenient secondary unlock.
Cellebrite documentation and has stated they'll upload future versions of it if you want to look at the rest of it:
https://discuss.grapheneos.org/d/12848-claims-made-by-forensics-companies-their-capabilities-and-how-grapheneos-fares/4
We have info on XRY, Graykey and others but not the same level of reliable details as this.
based on leaked Cellebrite documentation. Shows GrapheneOS does a much better job than iOS/Android blocking exploits and only Pixel 6 and later or iPhone 12 and later successfully stop brute forcing.