Metr0pl3x on Nostr: April release of the Pixel boot chain firmware includes fixes for 2 vulnerabilities ...
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.
source.android.com
Android Security Acknowledgements | Android Open Source Project
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 about ongoing work we spotted on wipe-without-reboot support.
Google is publicly working on a fix for the factory reset vulnerability we reported:
https://android-review.googlesource.com/c/platform/frameworks/base/+/3008138
Currently, apps using device admin API to wipe do not provide any security against a local attacker since you can interrupt them. Forensic companies are aware of this.
Show more
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.
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.
source.android.com
Android Security Acknowledgements | Android Open Source Project
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 about ongoing work we spotted on wipe-without-reboot support.
Google is publicly working on a fix for the factory reset vulnerability we reported:
https://android-review.googlesource.com/c/platform/frameworks/base/+/3008138
Currently, apps using device admin API to wipe do not provide any security against a local attacker since you can interrupt them. Forensic companies are aware of this.
Show more
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.