CVE-2024-32896: wipe-without-reboot added to AOSP due to reports by GrapheneOS

matchboxbananasynergy

Twitter / X: https://x.com/GrapheneOS/status/1801221485324800417
Mastodon: https://grapheneos.social/@GrapheneOS/112609239806949074
Bluesky: https://bsky.app/profile/grapheneos.org/post/3kusm52mwk72c

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:

https://grapheneos.social/@GrapheneOS/112204428984003954

As we explained there, none of this is actually Pixel specific.

Bulletin:

https://source.android.com/docs/security/bulletin/pixel/2024-06-01

Attribution to us:

https://source.android.com/docs/security/overview/acknowledgements

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 is 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 https://grapheneos.social/@GrapheneOS/112462756293586146 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.

OpenSource-Ghost

Can these vulnerabilities be executed remotely or do they require to be in physical possession of devices?

Does QPR3 fix the 2 listed main issues?

Is this fix going to be part of QPR3 (low priority) release for extended support Pixel 4a 5G?

GrapheneOS

OpenSource-Ghost This is not about any remote vulnerabilities.

Is this fix going to be part of QPR3 (low priority) release for extended support Pixel 4a 5G?

We already shipped this fix in May. The earlier 2 fixes from April can't be shipped because they're firmware patches and there are no firmware updates for end-of-life devices. We plan to continue providing extended support for the Pixel 4a (5G) and Pixel 5 but it's not relevant to this, and they're not secure devices anymore due to lack of firmware/driver patches. These are far from the most serious firmware patches they aren't receiving anyway. They don't get fixes for remote code execution vulnerabilities in Wi-Fi and cellular firmware, among others. They don't get fixes for GPU driver remote code execution bugs, etc.

de0u

GrapheneOS Am I right to believe that there is not a published list of known vulnerabilities for these devices, even though vulnerabilities are known to or at least suspected by Google and the GrapheneOS team and thus, presumably, known to motivated attackers?

GrapheneOS

de0u The Android Security Bulletin and Pixel Update Bulletin essentially provide that but it's hard to decipher the hardware-specific part of the ASB or the overall PSB. For example, this is the wipe-without-reboot backport they applied in Android 14 QPR3 and listed as a Pixel Firmware fix in the ASB because they shipped the original partial fix as a firmware mitigation and therefore the full fix in AOSP got classified as a Pixel Firmware patch (they made a typo and it says Pixel Firmwire in https://source.android.com/docs/security/bulletin/pixel/2024-06-01) when it really isn't one:

https://android.googlesource.com/platform/frameworks/base/+/bad78169b11942f408c68700b9ba96833ee82c7d%5E%21/

This seems to be part of why they didn't realize it should get backported and put in the Android Security Bulletin, but we've let them know that and they will:

https://grapheneos.social/@GrapheneOS/112674303870524129

We tried to get them to change the June 2024 bulletin to say Framework for this but it doesn't seem like they are going to do that based on what we said and we don't want to bother them about fixing something inconsequential, not worth the effort.