final [GrapheneOS] ๐Ÿ“ฑ๐Ÿ‘๏ธโ€๐Ÿ—จ๏ธ's avatar
final [GrapheneOS] ๐Ÿ“ฑ๐Ÿ‘๏ธโ€๐Ÿ—จ๏ธ
npub1c9d9...sqfm
Keeping the fight. Community Moderator for #GrapheneOS https://discuss.grapheneos.org/u/final This is a personal account. I do not speak on behalf of GrapheneOS developers as a whole (nor am I) and suggestions shall not be endorsements.
#GrapheneOS: Google is publicly working on a fix for the factory reset vulnerability we reported: You can see the work Google is doing here: 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 and take advantage of this. We weren't sure if they would even consider this to be a valid vulnerability but it was accepted as a High severity issue with a $5000 bounty. We also reported what we consider a far more serious firmware vulnerability which received a $3000 bounty due to not having full info. They're going to be shipping the mitigation we proposed for preventing obtaining data via exploiting vulnerabilities in firmware boot modes in the April security update. We also proposed software improvements which may ship soon. We aren't sure when factory reset will be fixed. GrapheneOS provides substantial defenses against obtaining data from devices in the After First Unlock state. We recently made major improvements in this area including our new USB-C port control feature able to disable data lines at a hardware level, unlike the standard feature. 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. 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. Our main defenses against this are our standard exploit protection features: Wiping freed memory in kernel/userspace also helps beyond exploit mitigation. We also added full compacting GC for core processes when locking and we're working on much more. We've planned to support adding a PIN as a 2nd factor for fingerprint unlock since 2016. A new contributor has recently made a lot of progress on it. We'll get it done after duress PIN/password. It will allow using passphrase primary unlock with fingerprint+PIN secondary unlock.
#GrapheneOS version 2024032100 released: This is a larger update containing a lot of fixes for apps or apps using libraries that are breaking with Android 14 QPR2. The temporary Bluetooth compatibility toggles have also been removed as Bluetooth devices should be fixed. See the changes: - Bluetooth: revert broken upstream change and changes depending on it to fix Galaxy Watch 6 Classic and likely other devices impacted by the same issue (this was a failure of upstream testing and release engineering for AOSP and doesn't impact the stock Pixel OS because it uses a different APEX module revision branched from an older revision of AOSP but it will impact every other AOSP-based OS on Android 14 QPR2 since there isn't a Bluetooth mainline module published in the Play Store and AOSP yet) - Android Runtime: disable stripping symbols for libart to restore compatibility with many obfuscated Chinese apps using a specific obfuscation SDK which was broken by Android 14 QPR2 when not using the mainline ART module due to the mainline module being based on an older codebase - Android Runtime: remove Android's hard-wired speed-profile compilation for launcher apps which was limiting ahead-of-time compilation for user installed launcher apps to the parts of the code included in baseline and/or cloud profiles rather than compiling the whole app via our default speed compilation which we use to replace JIT compilation and JIT profiles guiding background AOT compilation - backport 12 upstream fixes from the mainline MediaProvider, Wifi, NetworkStack and HealthFitness APEX modules - allowlist using device controls quick tile when unlocked since it already has a toggle for controlling availability so our new default requirement of the device being unlocked needs to be overridden for it - revert disabling hardened_malloc for Broadcom Bluetooth HAL (does not appear to be a memory corruption bug found by GrapheneOS but rather the stock OS is using an older Bluetooth module without the issue) - revert allowing users to disable Bluetooth for Bluetooth system app (does not appear to be a memory corruption bug found by GrapheneOS but rather the stock OS is using an older Bluetooth module without the issue) - more complete setup design configuration to improve appearance of Setup Wizard, etc. - Settings: fix upstream footer formatting issue for App pinning screen - update timezone module to Android mainline 341510010 (based on tzdata 2024a) - kernel (5.15, 6.1): improve support for hosting servers by enabling SYN cookies as we do for the older kernels - kernel (6.1): drop obsolete usage of YAMA which we replaced with our dynamic SELinux flag extension - kernel (5.10): update to latest GKI LTS branch revision - GmsCompatConfig: update to version 99
#GrapheneOS: Our users have found additional Android 14 QPR2 Bluetooth memory corruption bugs which so far appear to be specific to pairing recent Galaxy Watch devices with GrapheneOS. We're working on finding and fixing this as we did with the BLE audio bugs. The Android 14 QPR2 Bluetooth LE audio bugs we found were fixed in the March 9th release of GrapheneOS: We also reported it as an #Android vulnerability in the same day and it has been initially triaged by them as a High severity and High quality report. Users on the stock OS are experiencing Bluetooth regressions with Android 14 QPR2 too. These latent and often exploitable bugs breaking functionality for certain users in certain situations often get turned into reliable crashes/breakage due to our memory corruption protections. The downside is that more of our users get impacted by the issues and they tend to break a specific niche feature completely such as whatever is being used by the Galaxy Watch. On the stock OS, it breaks for some users and may break in a subtle way such as corrupting other data. The upside is our users are protected against exploitation through these bugs and many others. Since the issues stop being subtle and turn into reliable breakage, it also forces us to look into what's wrong and we often figure out how to fix it completely as we did for BLE audio. The end result is that GrapheneOS users end up with an OS that's not just more secure but has additional bug fixes since our exploit protections force us to fix these issues right after they're introduced instead of remaining dormant breaking things for some users for months. #security #privacy
โ†‘