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 version 2024040900 released: - rebased onto AP1A.240405.002.A1 Android Open Source Project release (includes a launcher taskbar improvement) - avoid crashes in Chromium-based web browsers and the WebView in their sandboxed processes caused by an incompatibility between exec-based spawning and the new userfaultfd-based garbage collector enabled by Android 14 QPR2 - DNS resolver: fix upstream bug resulting in NUL byte being included in the random string for the DNS-over-TLS test query - allow privileged installers to use getSharedLibraries(MATCH_ANY_USER) in order to enable Apps to handle an edge case involving shared libraries (Vanadium Trichrome library) updated in other users while avoiding adding the INTERACT_ACROSS_USERS permission used for this purpose by the Play Store - kernel (5.10, 6.1): update to latest GKI LTS branch revision - kernel (5.10): reapply reverted upstream f2fs and irq changes now that the regressions are resolved - GmsCompatConfig: update to version 102 - fix our infrastructure for testing our CarrierConfig2 app
We posted about on the Digital Forensics Discord (.gg/digitalforensics) used by DFIR students, law enforcement, employees of Cellebrite, MSAB, GrayKey etc. It's on-topic and they've regularly talked about GrapheneOS, but they got upset about it and banned our project account. 🀷 People who work at Cellebrite, NSO, law enforcement agencies, etc. are welcome to use GrapheneOS and participate in our community. We would appreciate posts from people working in these secretive industries "helping" us improve security for GrapheneOS, Pixels and Android πŸ˜‰
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. 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: 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.
#GrapheneOS Version 2024040200 released. See the changes: - full 2024-04-01 security patch level (early release based on AOSP 14 April security backports since the official April AOSP and stock Pixel OS monthly releases aren't available yet) - fix race condition for Wi-Fi and Bluetooth auto-turn-off leading to the first auto-turn-off timer after the first Wi-Fi or Bluetooth state update potentially not being scheduled - fix Wi-Fi auto-turn-off no longer handling Wi-Fi state change events not involving a Wi-Fi network DocumentsUI (Files): do not delegate handling of downloaded APKs to DownloadProvider to avoid confusing install permission prompt - flash-all: raise minimum fastboot version to 34.0.5 - kernel (Pixel 8, Pixel 8 Pro): sign vendor modules after building them instead of only signing generic (GKI) modules - kernel (6.1): update to latest GKI LTS branch revision - fix upstream bug breaking pressing power button 5 times to make an emergency call - fix upstream bug causing 5 second delay to start the emergency dialer for the first time - CarrierConfig2 (app created by GrapheneOS to replace Google CarrierSettings): add stub implementation of VendorConfigProvider - Setup Wizard: use new API for emergency calls - Setup Wizard: add prompt for unlocked bootloader triggering reboot to fastboot mode to lock - Setup Wizard: add prompt for disabling OEM unlocking after the device is locked (will be disabled by default) - GmsCompatConfig: update to version 100 - GmsCompatConfig: update to version 101 - Vanadium: update to version 123.0.6312.80.0 - Vanadium: update to version 123.0.6312.80.1
#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.
↑