KindnessInfinity

Notable changes in version 22:

• skip renamed packages on initial GrapheneOS 14 QPR2 versions due to upstream original-package bug resolved for the next GrapheneOS release (i.e. users who still have an install from before Vanadium was renamed to app.vanadium.browser from org.chromium.chrome will need to wait until the next GrapheneOS release to update it)
• update Gradle to 8.6
• update Kotlin to 1.9.23
• update Kotlin Symbol Processing to 1.0.19
• update Android Gradle plugin to 8.3.0
• update Bouncy Castle to 1.77
• update AndroidX Activity KTX to 1.8.2
• update AndroidX Fragment KTX to 1.6.2
• update AndroidX Navigation libraries and Safe Args plugin to 2.7.7
• update Material Components library to 1.11.0
• update KotlinX Coroutines to 1.8.0
• update AndroidX lifecycle libraries to 2.7.0

A full list of changes from the previous release (version 22) is available through the Git commit log between the releases.

Apps is the client for the GrapheneOS app repository. It's included in GrapheneOS but can also be used on other Android 12+ operating systems. Our app repository currently provides our standalone apps, out-of-band updates to certain GrapheneOS components and a mirror of the core Google Play apps to make it easy for GrapheneOS users to install sandboxed Google Play with versions of the Google Play apps we've tested with our sandboxed Google Play compatibility layer.

GrapheneOS users must either obtain GrapheneOS app updates through our app repository or install it with adb install-multiple with both the APK and fs-verity metadata since fs-verity metadata is now required for out-of-band system app updates on GrapheneOS as part of extending verified boot to them.

Android is moving towards completing one of the areas of verified boot which currently only works in GrapheneOS. They never fully adopted verifying out-of-band system APK updates with fs-verity and then disabled it. They're moving towards using APK Signature Scheme v4.

Changes in version 122.0.6261.119.0:

• update to Chromium 122.0.6261.119
• extend open external links in Incognito toggle to share intent

A full list of changes from the previous release (version 122.0.6261.105.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

https://grapheneos.social/deck/@GrapheneOS/112081050753600852

Our recently added low-level USB-C port control feature is now enabled by default. Default mode disables new data connections once the device is locked after the initial unlock. It fully disables the data lines once any existing connections finish.

This is far superior to the standard USB toggle added in Android 12 to the USB HAL and device admin API. That only allows disabling USB at a high level and leaves all the low-level kernel USB driver/protocol and firmware attack surface enabled. It's also simply either on or off.

We also improved the usability of the feature by resetting the USB port when unlocking the device for modes that are charging-only while locked. This causes devices first connected while locked to be detected on unlock. We wanted to address this before enabling it by default.

Our previous USB peripheral control option will likely be removed on devices supporting the new feature, so it will only need to be kept on 5th generation devices. In theory, we could probably implement the new feature for those, but it requires complex device-specific work.

The other major new feature is fully enabling PAC/BTI for userspace on the Pixel 8 and Pixel 8 Pro. Stock OS currently only enables PAC for the kernel where we already enabled BTI to cover functions excluded from type-based CFI. MTE was our priority since it's far more impactful.

We want to enable stack allocation MTE but we need to make sure it works with all of the OS including Chromium's garbage collector stack scanning in Vanadium. Other Chromium-based browsers disable MTE at runtime and Firefox doesn't currently use it, so they don't really matter.

SSP is fully obsoleted by properly implemented stack allocation MTE but the issue is that not everything is compatible with MTE so SSP still needs to be enabled for everything they might use. We have a similar issue with canaries in hardened_malloc which we can't disable yet.

Our features page (https://grapheneos.org/features) needs massive updates to cover everything we've added and changed recently. We'll try to document most of the new major features there in the next few days. It also needs a lot of expansion for the existing features it already covers.

Tags:

• 2024031100 (Pixel 5a, Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, emulator, generic, other targets)

Changes since the 2024030900 release:

• toggle USB port after device unlock to automatically detect a device plugged in while it was in charging-only mode while locked, etc.
• Tensor Pixels: change default mode for our USB-C port control feature able to truly disable USB at a hardware level to "Charging-only when locked, except before first unlock" (doesn't apply to connections that were made before locking or first unlock) which can be changed by users in Settings > Security > USB-C port
• fix Wi-Fi auto-turn-off issues leading to it not triggering in certain cases caused by backwards incompatible changes in Android 14 QPR2
• Pixel 8, Pixel 8 Pro: fix enabling DisplayPort alternate mode support
• Pixel 8, Pixel 8 Pro: fully enable PAC and BTI for userspace too, especially since ShadowCallStack is not currently used in userspace and Clang type-based CFI is only used for a large subset of the important userspace code
• GmsCompatConfig: update to version 98
• improve internal infrastructure used by GrapheneOS features

We're continuing work on integrating ARMv9 security features. MTE is the highest impact and most interesting of these features, but there's less important work to do expanding usage of PAC and BTI. Android uses Clang's type-based CFI but not everywhere so BTI is still useful

Pixel 8 was the first device with a usable MTE implementation despite it launching as part of ARMv8.5. Android world stayed on ARMv8.2 until ARMv9 and Apple hasn't shipped MTE. Apple was a much earlier adopter of the much less useful PAC. From our perspective, PAC was a misstep.

PAC is a weak probabilistic mitigation requiring lots of case-by-case integration. MTE can provide many deterministic guarantees and does a much better job as a probabilistic mitigation by catching memory corruption rather than only protecting specific memory corruption targets.

PAC requires bits which would have been better served by 16-bit MTE support and using a 48-bit address space. Hardware shadow stack is a better backwards edge CFI approach. MTE could be used to mimic hardware shadow stack support via a reserved tag for ShadowCallStack.

We're currently the first platform using userspace heap MTE for hardening in production. We plan to do the same with userspace stack MTE along with doing both in the kernel. Turning ShadowCallStack in the kernel into a hardware protected shadow stack would also be nice to ship.

In the kernel, Pixel OS uses PAC for backwards edge CFI and Clang type-based CFI for forward-edge. We use ShadowCallStack + PAC together and enable BTI in addition to type-based CFI due to lots of functions being excluded from type-based CFI. We plan to do the same in userspace.

Changes in version 98:

• update max supported version of Play services to 24.09
• update max supported version of Play Store to 40.0

A full list of changes from the previous release (version 97) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GM's comp at on fig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

Tags:

• 2024030900 (Pixel 5a, Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, emulator, generic, other targets)

Changes since the 2024030800 release:

• fix upstream Android 14 QPR2 use-after-free bug impacting Bluetooth LE audio with certain devices (reliably caught by our hardware memory tagging integration on the Pixel 8 and Pixel 8 Pro, but also impacts previous devices which still have the standard hardened_malloc mitigations for use-after-free)
• Settings: hide placeholder dates for Battery information screen in Settings > About device due to 6th/7th generation Pixel batteries having a placeholder value for the first use date

Our hardware memory tagging support for Pixel 8 and Pixel 8 Pro has uncovered a memory corruption bug introduced in Android 14 QPR2 for Bluetooth LE. We're currently investigating it to determine how to fix or temporarily disable the newly introduced feature as a workaround.

Disabling memory tagging for this process isn't an acceptable workaround even in the short term because it's a major attack surface whether or not this particular bug turns out to be exploitable. This only occurs with certain Bluetooth LE devices, not all Bluetooth devices.

We've developed a patch for the upstream Android 14 QPR2 use-after-free bug we discovered with Bluetooth LE. Our priority is getting out a GrapheneOS release with our fix soon and we'll report it as an Android security bug. This should resolve the BLE audio regressions too.

A user able to reproduce the issue with Samsung Galaxy Buds2 Pro in Bluetooth LE mode has confirmed our fix works. This issue also impacts stock Pixel OS. GrapheneOS detects it via hardened_malloc memory tagging support and we added MTE crash notifications with a report to send.

This use-after-free has been reported as a security bug (b/328916844 for Googlers).

Our initial minimally invasive patch:

https://github.com/GrapheneOS/platform_packages_modules_Bluetooth/commit/e295e5888f97ba11a4d07aff3b6bc48b2512831c

This code needs a major refactor and shouldn't be using raw pointers, but we want to avoid introducing new bugs with a quick patch.

Android has ported a lot of the Bluetooth code to Rust. This is a demonstration of why they need to put more resources into porting the rest of the code into Rust.

They should also be testing HWASan and MTE builds with more real world usage including using assorted BT devices.

Pixels shipped a massive hardware security feature (MTE) they aren't enabling for the OS to save 3.125% memory/cache usage. It's silly. Heap MTE has near 0% perf overhead in async mode and is cheaper than increasingly ineffective legacy mitigations like SSP in asymmetric mode.

GrapheneOS enables MTE for the base OS and known compatible user installed apps by default. There's a user-facing opt-in via Settings > Security to turn it on for all user-installed apps. We provide a clear notification with a crash report to copy and a per-app toggle for it too.

We provide a nicer MTE implementation as part of hardened_malloc which uses the standard random tags with a dedicated free tag but adds dynamic exclusion of previous tag and current (or previous) adjacent tags. We also fixed Chromium's integration and will improve PartitionAlloc.

GrapheneOS is the first platform using MTE in production, and does a lot more too:

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

Our Vanadium browser is the first browser using it in prod:

https://grapheneos.org/features#vanadium

We plan to add stack MTE, improve PartitionAlloc and make new kernel slab MTE.

This issue was fixed in the March 9th release of GrapheneOS:

https://grapheneos.org/releases#2024030900

We also reported it as an Android vulnerability in the same day and it has been initially triaged as a High severity and High quality report.

We're working on additional reports from users.

GrapheneOS based on Android 14 QPR2 has been heavily tested by our users over the past 2 days and should reach the Stable channel within a few hours.

You can help with final Beta channel testing if you want. The only known regression is Wi-Fi auto-turn-off not always triggering.

Wi-Fi auto-turn-off will be fixed in a near future release. It isn't a release blocker because there are a bunch of important privacy and security patches that are far more important than a minor attack surface reduction feature. You can turn off Wi-Fi yourself for a couple days.

Tags:

• 2024030800 (Pixel 5a, Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, emulator, generic, other targets)

Changes since the 2024030700 release:

• add back unlocking requirement for the new Internet quick tile in QPR2
• ThemePicker: restore themed icon and grid settings for QPR2 port
• DocumentsUI (Files): work around crashes caused by QPR2 R8 changes resulting in code used via reflection being removed

Google has awarded bounties of $5000, $3000 and $250 for our 3 vulnerability reports related to physical data extraction attack vectors. Both $5000 and $3000 issues are being exploited in the wild. $250 bounty is for a minor issue we found while doing general USB hardening work.

Most serious issue is the one with a $3000 bounty. We provided proof of in the wild exploitation and a proposal for preventing exploiting the class of vulnerabilities which is being implemented. For the one they're awarding $5000, we weren't sure they'd even consider it a bug.

The most serious issue is likely only getting $3000 because we do not know the specific bug being exploited. It was classified a low quality report, not because we did a bad job but because we don't have that info. We did provide a way to prevent getting data by exploiting it.

Our proposal for preventing getting data by exploiting the main issue should ship as a Pixel firmware update next month and the feature will become one of our baseline hardware requirements. It's already harder to use it with GrapheneOS and we've made major recent improvements.

Our recent improvements:

1. New USB-C port control setting integrated into the USB-C controller driver to disable USB at a hardware level. It will become "Charging-only when locked, except before first unlock" by default soon. Shipped in 2024022600: https://grapheneos.org/releases#2024022600

2. We reimplemented our auto-reboot feature with a more hardened implemention which can't be bypassed by crashing system processes. This starts a timer when the device is locked which reboots unless it's successfully unlocked first. Shipped in 2024011300: https://grapheneos.org/releases#2024011300

3. We reduced the default auto-reboot timer from 72 hours to 18 hours. This also shipped in 2024011300. 18 hours is enough that users don't encounter it in practice as long as they unlock their phone a couple times per day. Users who need max security can use 10 minutes.

4. We run a full compacting garbage collection in SystemUI and system_server when the device is locked. Android already does this after unlock to clear credentials. Goes well with our kernel zero-on-free since it zeroes the data. Shipped in 2024020500: https://grapheneos.org/releases#2024020500

Our main proposal should ship for the Pixel firmware in April, resulting in the firmware's fastboot mode fully clearing all of the device's regular memory before enabling USB. We could implement the same thing for the OS to make sure there's no data left from an unclean reboot.

Forensic companies keep misrepresenting adding support for extracting data from GrapheneOS via ADB based on a user providing lock method as being something more in their marketing. This is start of our response. We'll be pushing for much bigger changes for Android and Pixels.

We fully intend to make the same proposals to other Android OEMs like Samsung. We're starting with Pixels because they're the devices we use due to their high level of security. We're also going to begin advocating for big changes like encrypted memory and funding PoC attacks.

We've been working on a duress PIN/password feature for a while that's nearly ready to ship. It's taking so long because we had to prevent bypasses impacting existing panic / duress wipe apps and OS features. We also decided to do the USB-C control and auto-reboot features first.

Since 2016, we've planned to support adding a PIN as a 2nd factor for fingerprint unlock. A new contributor has started working on this feature. We'll get it done after duress PIN/password. This will allow using passphrase primary unlock with fingerprint+PIN secondary unlock.