Vulnerabilities exploited in the wild fixed based on GrapheneOS reports

matchboxbananasynergy

Twitter / X: https://twitter.com/GrapheneOS/status/1775305179581018286
Mastodon: https://grapheneos.social/@GrapheneOS/112204428984003954
Bluesky: https://bsky.app/profile/grapheneos.org/post/3kp6teuq3mc2x

April release of the Pixel boot chain firmware includes fixes for 2 vulnerabilities reported by GrapheneOS which are being actively exploited in the wild by forensic companies:

https://source.android.com/docs/security/bulletin/pixel/2024-04-01
https://source.android.com/docs/security/overview/acknowledgements

These are assigned CVE-2024-29745 and CVE-2024-29748.

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.

We proposed zeroing memory in firmware when rebooting to fastboot mode to wipe out the whole class of attacks. They implemented this by zeroing memory when booting fastboot mode. USB is only enabled by fastboot mode after zeroing the memory is completed, blocking these attacks.

GrapheneOS already implemented defenses against this attack before we became aware of it. After becoming aware of this attack against Pixels running the stock OS, we improved our existing defenses and added new ones alongside reporting the firmware weaknesses to get those fixed.

CVE-2024-29748 refers to a vulnerability providing the ability to interrupt a factory reset triggered by a device admin app. It appears they've implemented a partial solution in firmware. See https://twitter.com/GrapheneOS/status/1772616917611585809 [mastodon link] [bluesky link] about ongoing work we spotted on wipe-without-reboot support.

GrapheneOS has been working on a duress PIN/password feature for a while, and as part of that we already implemented our own wipe-without-reboot system. We care a lot about doing things properly and the way this was done in existing apps and operating systems was highly insecure.

Can see the announcement of these being exploited in the wild at https://source.android.com/docs/security/bulletin/pixel/2024-04-01#Announcements.

In addition to them working on our proposal to implement wipe-without-reboot, we've spotted work on our other suggestions such as wiping key derivation results from memory after unlocking.

In the near future, we'll be shipping a properly secure implementation of a duress PIN/password along with a properly secure panic wipe based on wiping without requiring a reboot. We also plan to make device admin API use our wipe-without-reboot approach until Android ships one.

Our baseline defenses against attacks aiming to extract data from After First Unlock state devices are our generic exploit protection features:

https://grapheneos.org/features#exploit-protection

Wiping freed memory in kernel/userspace helps beyond exploit mitigation by avoiding having data kept around.

Our auto-reboot feature starts a timer after the device is locked which will reboot the device is it isn't unlocked successfully before the timer elapses. This is set to 18 hours by default but can be set between 10 minutes and 72 hours. It won't chain reboot the device anymore.

All of our defenses against obtaining data from After First Unlock state devices are centered around auto-reboot. Our goal is preventing exploitation long enough for the device to cleanly reboot and get the data back at rest as if it had been obtained while it was powered off.

Due to the importance of auto-reboot, we recently reimplemented it as a low-level timer in the init process. This makes it much harder to prevent the device from rebooting. Previously, crashing system_server would restart the timer. It also allowed us to avoid it chain rebooting.

Our USB-C port control is set to "Charging-only when locked, except before first unlock" by default. New USB connections can only be made while unlocked, except BFU. After locking, new connections are blocked immediately and data lines are disabled when existing connections end.

We encourage users to use "Changing-only when locked" if they don't need USB devices when the device boots or "Charging-only" if they don't use USB beyond charging. There's also an "Off" value disabling charging when OS is booted into the main OS boot mode for high threat models.

To clarify something that's being misunderstood, neither of these 2 weaknesses are specific to Pixels. The mitigations they added are specific to Pixels. We aren't aware of another Android device implementing the reset attack mitigation shipped by Pixels based on our proposal.

The specific vulnerabilities being exploited in fastboot mode are likely littlekernel USB vulnerabilities. If you look in the Pixel security bulletins, you can see many of the patches there are for components also used on other devices like the Samsung modem and littlekernel.

L8437

matchboxbananasynergy
Please can someone explain, or point me to the right information.

What does it mean "charging only when locked, before first unlock"

I don't understand "before first unlock" with regards to a usb being plugged in

Turtle12345

What do you mean with partitial solution for CVE-2024-29748 does that mean the fix is not complete?

GrapheneOS

Turtle12345 It appears they've changed the firmware to stop the reboot to recovery for wiping being interrupted, but it's still not stealthy and the device could still have the power cut off, etc. before it completes. Wiping without rebooting is the full solution which we'll still need to implement ourselves for our duress PIN/password feature until they have an implementation that's included.

Turtle12345

GrapheneOS

Thanks for the explaination! Do you know if they (Google) are going to implement it?

[deleted]

L8437 https://discuss.grapheneos.org/d/11178-grapheneos-version-2024022800-released/12

The options and their meanings:

On - This means the USB-C port is on, like it would be on Stock OS. No restrictions.

Charging-only when locked, except before first unlock - this will likely become the new default. It means that the USB port will be fully functional when the device is in BFU, and when the device is unlocked. When the device is in AFU, but locked, it will only charge. If you plug in something while the device is in BFU or when unlocked, and then lock it, it doesn't kill that existing connection. This makes sense for most people as it has a very minimal impact on day-to-day use. If you use a keyboard and a USB hub for a screen on an 8th gen Pixel, for example, because connections work in BFU, you'll be good to go right away. When the device is unlocked, it makes sense for the port to be usable so you can plug stuff in. That said, the port being disabled except for just charging makes sense when it's in AFU but locked, in case someone takes the phone and tries to exploit it.

Charging-only when locked - This is similar to the above, but the difference is that here, the port only charges in BFU as well, which means less attack surface when the device is in BFU, but the tradeoff is that you cannot connect a keyboard etc. for the first unlock.

Charging-only - this one should be self explanatory, but just in case it isn't, this means that no matter if the phone is in BFU or AFU, locked or unlocked, the port can only be used for charging. It's important to keep in mind here that if someone gets access to the device while it's unlocked, they can simply change the option in security settings to "on" etc.

Off - as mentioned before, this is the most aggresive option, disabling the port entirely in the OS but allowing you to charge when the phone is powered off.

L8437

[deleted] fantastic! Thanks for the explanation.

Because of this, I was able to change my owner pin to using a password....but where i manually enter characters + press yubikey to add extra characters

If this makes sense

ClownsDarkSoulPerps

Thanks for your efforts

UndercoverBozo

The heroes we need but dont deserve.

matchboxbananasynergy

A follow up:

Twitter / X: https://twitter.com/GrapheneOS/status/1775619234204197234
Mastodon: https://grapheneos.social/@GrapheneOS/112209146491225997
Bluesky: https://bsky.app/profile/grapheneos.org/post/3kpavxfn2yi2c

Reset attack mitigation for firmware-based boot modes such as fastboot mode has been added as one of our requirements for GrapheneOS support:

https://grapheneos.org/faq#future-devices

It shipped as part of this month's firmware updates for Pixels based on our proposal. Other OEMs should add it.

See our thread at https://grapheneos.social/@GrapheneOS/112204428984003954 for more details. It was added to prevent extracting data via fastboot mode vulnerabilities exploited in the wild. There are now 3 features on our list of hardware requirements where we played a major role in getting them added to Pixels.

GrapheneOS

@TrustExecutor Your reply has been removed for posting links to misinformation from a highly malicious account spreading massive amounts of misinformation about GrapheneOS for years as part of promoting a proprietary product. As usual, their claims are highly inaccurate. One of these two vulnerabilities mainly refers to the lack of an exploit mitigation which is now deployed for Pixels but not elsewhere. The other refers to an app vulnerability caused by AOSP not implementing support for wipe-without-reboot. Pixels partially worked around the 2nd issue in firmware but a proper solution will require both AOSP to support wipe-without-reboot which they're working on implementing. Please don't link to content from this malicious account. We cannot reply on Reddit because they've blocked the project account, developer accounts, moderator accounts, etc. which on Reddit prevents participating in any thread they create including not just their posts but the thread from a comment. Someone they've blocked can't even reply to someone who replies to their comment, and they use this as a weapon to spread misinformation.

GrapheneOS

@TrustExecutor Their claims about auto-reboot and disabling reboot on the lockscreen are also completely wrong. A clean reboot on GrapheneOS is a good thing due to zero-on-free. A clean reboot or shutdown kills the processes which frees the slab and page memory tied to them, resulting in it being zeroed. That's how GrapheneOS defended against attacks via firmware boot modes. It isn't adequate because an attacker can trigger a reboot in another way. Shutting down the device also doesn't magically clear all the memory but rather it starts degrading once it's no longer powered. The reason we cared so much about having the firmware perform reset attack mitigation is because an attacker can trigger a hard reset by opening up the phone and causing any kind of fault which triggers it to crash and reboot. If they press reboot in the OS, they're helping by zeroing the data via a clean reboot. Disabling rebooting while locked wouldn't help anything and the whole point of auto-reboot is to do that automatically after a timer expires to get the memory zeroed. The person you're linking to doesn't understand security but pretends as if they do and spreads massive amounts of misinformation about it.

TrustExecutor

GrapheneOS Thanks for your educational reply. This is what I first suspected, a inferior competing OS spreading a bad narrative about GrapheneOS. I will stop linking to what I suspect is misinformation.

And he is obviously pushing the "government backdoor in Pixels" narrative, at the same time ignoring the lack of field reports of those backdoors being used. The fact that the forensic companies has to revert to using an exploit is quite telling of the Pixel's security. The swedish police had an investigation where they could not extract data from a Pixel running GrapheneOS, and I bet they have access to all the latest and most exotic forensic tech.

L8437

GrapheneOS hi there what do you mean by a "clean reboot"

Is this pressing "restart" from the power menu?
Auto reboot timer ?
What about "power off" option from the power menu?

Am I guessing that a NON clean reboot is when the system crashes and reboots, but it takes alot shorter time to start?

GrapheneOS

TrustExecutor If you look into it, it's a proprietary OS based on Android 11 LineageOS with incomplete Android privacy/security patches. It's made for insecure OnePlus devices. They're trying to get money by convincing people that's worth buying from them. They're heavily invested in peddling misinformation about GrapheneOS, DivestOS, Android, Pixels and other things. It appears motivated by more than simply selling a few people their scam OS.

Resurr

TrustExecutor The swedish police had an investigation where they could not extract data from a Pixel running GrapheneOS

Could you provide a link for this?

Xtreix

GrapheneOS The developer you're talking about's only argument is "trust me bro" and his scam could well be used for malicious purposes, its developer effectively spreads misinformation about GrapheneOS, Pixel etc.

GrapheneOS

L8437

Is this pressing "restart" from the power menu?

Any regular reboot triggered by the OS. Restart in the power menu, auto-reboot, idle reboot after update if enabled in the update client, reboot triggered by a device admin app, etc.

Am I guessing that a NON clean reboot is when the system crashes and reboots, but it takes alot shorter time to start?

You're referring to system_server crashing, which respawns system_server and other system processes. That's not really a reboot at all, although it's often called a soft reboot. It's not what is being referred to by an unclean reboot. An unclean reboot would be a hardware/firmware/software fault causing a hard reset without the OS cleanly shutting things down.

L8437

GrapheneOS thank you for this reply, I appreciate your help.

Can I ask, probably a stupid question.
If you power off the phone, does that have the same effect as restarting , or is there more risk with a power off

GrapheneOS

L8437 The advantage of the phone being powered off is that the memory will rapidly begin to degrade. The advantage of the phone being rebooted is that the firmware or OS can zero the memory explicitly. Aside from improved usability, another reason we prefer to reboot is because we're going to be doing explicit zeroing of all memory at boot for the OS similar to how fastboot mode now does it based on our proposal. This provides an opportunity to zero anything not already zeroed as part of our zero-on-free implementation which zeroes the freed allocations and freed pages as part of the process of ending the OS running.