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:




These are assigned CVE-2024-29745 and CVE-2024-29748.source.android.com/docs/security/…
source.android.com/docs/security/… 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've added documentation for the hardware memory tagging implementation in hardened_malloc:



GrapheneOS on Pixel 8 / Pixel 8 Pro is the first platform using ARM MTE in production. Stock Pixel OS has it as a hidden development option requiring using ADB.github.com/GrapheneOS/har… GrapheneOS uses hardened_malloc as the system allocator and enables memory tagging by default. MTE is enabled for all base OS apps and nearly all executables. It's only temporarily disabled for surfaceflinger (due to upstream bug in Android 14 QPR1) and a few vendor executables.

Earlier this month, unknown attackers targeted our website servers by spamming requests in an attempt to overload the servers and prevent users from accessing out website. We provided detailed information on what was happening and how we responded to it.

https://twitter.com/GrapheneOS/status/1623604628993589248

We made it clear we don't know the specific group behind that specific DDoS attack. In response to , we explained it's not a sophisticated attack and very likely originates from groups who openly engage in other forms of underhanded attacks on GrapheneOS.

https://twitter.com/kitfunfel/status/1623632234971545600

Our website was targeted with a Distributed Denial of Service attack using HTTP/2 multiplexing within the 2 minute window from 2023-02-09T00:58:00Z to 2023-02-09T01:00:00Z. OVH detected it and enabled mitigation but enough went through to cause downtime due to memory limits. In September, a similar attack caused nginx's master process to be killed by the out-of-memory killer causing much longer downtime. Default systemd service lacked auto-restart since master process supervises workers. We fixed that:

github.com/GrapheneOS/inf…
github.com/GrapheneOS/inf…

Uptime monitoring dashboard for the production GrapheneOS services is available at nodeping.com/reports/status…. Alerts are also posted publicly in our #infra:grapheneos.org Matrix room when a check is added, starts failing or stops failing. It's often not really an outage. For example, today, the TLS checks for attestation.app detected the certificate would expire in less than 15 days. This ended up being because the removal of a legacy subdomain several weeks ago broke automatic certbot removal. It can do much more advanced checks though.

Google publishes the source code for their TalkBack screen reader. GrapheneOS maintains a fork of it and includes it in GrapheneOS with the help of a blind GrapheneOS user who works on their own more elaborate fork. Eventually, we'd like to include more or all of their changes. TalkBack depends on a text-to-speech (TTS) implementation installed/configured/activated. It needs to have Direct Boot support to function before the first unlock of a profile. Google's TTS implementation supports this and can be used on GrapheneOS, but it's not open source.

We've purchased grapheneos.social and it we'll be hosting an official Mastodon instance for our project accounts there in the near future.

If you follow @grapheneos@infosec.exchange right now, you'll be automatically moved over to following the new account on our instance. fedifinder.glitch.me will scan the profiles of the people you follow on Twitter to find them on the fediverse (Mastodon). It helps you choose an instance and gives you a list of their handles to import into your new account so you can keep a lot of the people you follow there.

There are several dozen companies selling phones with GrapheneOS or forks of it. Many of these companies falsely claim to be partnered with us or working with us which isn't true. Most of these companies don't contribute back to GrapheneOS and try to get free support from us. It's easy to install GrapheneOS with grapheneos.org/install/web and we don't expect to have a revenue stream from selling phones not specifically made to run GrapheneOS. Still, it's quite problematic for companies to claim they are supporting us when they aren't actually doing it.

We independently discovered the Android lockscreen bypass fixed in Android's November security update while working on features like a duress PIN/password.

We had an initial patch developed by June 13 but by the time we submitted an upstream bug report, it was a duplicate issue. Can see the patch shown here was authored June 13th and it took a while for it to be developed and tested. Unfortunately, by prioritizing developing a fix for GrapheneOS users and not getting it immediately reported upstream our developer missed out on a life changing bug bounty.

https://twitter.com/GrapheneOS/status/1580732479031644161

This can't cause compatibility issues for apps from the Play Store, but there are more issues than expected with the app ecosystem outside the Play Store. Main issue is with an F-Droid repository redistributing developer builds that's not shipping 64-bit. Android's modern app distribution mechanism system is based around split apks generated from an app bundle (aab). Code/resources specific to architectures, locales or display sizes can be split out. App repository client has to install the base apk and the required splits for it.

We've discovered a bug on Pixel 7 and Pixel 7 Pro with hardware attestation support via the Titan M2 as part of adding Auditor support. Hardware attestation throws an error after an OS upgrade, likely due to incorrect handling of version binding updates for remote provisioning. We've reported this issue upstream and worked around in version 62 of our Auditor app:

https://twitter.com/GrapheneOS/status/1581055948189470720

We previously found a similar issue with the app-generated attest key feature introduced in Android 12 and initially shipped by the Pixel 6, Pixel 6 Pro and Pixel 6a.

Pixel 7 and Pixel 7 Pro have fully dropped support for 32-bit apps. We expected 7th generation Pixels to be ARMv9 devices without 32-bit app support but they dropped 32-bit app support despite remaining on ARMv8.2. Shift to ARMv9 has been pushed to next year for unknown reasons. Play Store stopped supporting publishing apps without 64-bit support on 2019-08-01 for both new apps and app updates. It stopped serving apps without 64-bit support to 64-bit capable devices on 2021-08-01. We expect there would be little impact from dropping it from GrapheneOS.

We avoid bundling third party apps and services since they're never fully aligned with our approach and goals.

Once an app is included, it's difficult to remove for existing devices since users depend on it. This would result in apps being included past their best before date. Many people wanted us to bundle Signal with GrapheneOS as the default SMS/MMS app. Signal is now dropping support for SMS/MMS. They also don't care much about keeping their dependencies patched, reducing attack surface or internal sandboxing. It would be an issue for GrapheneOS.

Connectivity checks are one of the 4 Google services used by AOSP. We replace these 4 services with GrapheneOS services by default with toggles to disable them or use the standard Google servers. Connectivity checks are low level and are run on each network to check if it works. Connectivity checks are a special case since they still need to detect whether each underlying network has internet access when you're using a VPN.

If you're using a VPN and want to hide that you use GrapheneOS, you should switch connectivity check toggle to Standard (Google).

We need $3500 to preorder 2x Pixel 7 and 2x Pixel 7 Pro (2x $599 + 2x $799 at local prices with added sales tax). One for main device maintainers and one for main dev/testing set.

Bitcoin donation address specifically for this purpose:
bc1q2fh6j65w3rfvyn00zex2gh9eslhw9nvdnvkfy7. We chose to keep things simple for this little fundraising effort. It's easiest to handle a specific funding goal with 1 currency and Bitcoin is how we distribute funds to developers.

grapheneos.org/donate has other donation options including Monero, Zcash and credit cards.

@Khajiit_san Each of those devices is already insecure and lacks basic industry standard security. A company advertising a device as having long term support but not actually being able to provide proper security updates and other support even currently is not meaningful, it's marketing. @Khajiit_san When a Pixel 6 is stated to have at least 5 years of support, that means it gets full Android and Pixel security updates for 5 years. When @Fairphone states they'll support devices for 5 years, they aren't including proper security updates, which they already don't provide today.

This is the Android 13 change likely causing compatibility issues between VPN lockdown (Block connections without VPN) and mobile data for some users on certain carriers:

android.googlesource.com/platform/packa…

Android 13 improved VPN lockdown with this change but they missed an exception. If you're one of the users on a carrier with the issue, you should be able to work around it without disabling the VPN: disable VPN lockdown and toggle airplane mode on and off to reconnect to the cellular network, then toggle VPN lockdown back on. Works around missing exception.

Certain carriers have compatibility issues with VPN apps with "Always-On" and "Block connections without VPN" enabled on Android 13. This issue is confirmed to impact the stock Pixel OS and AOSP. It isn't specific to GrapheneOS. It's also not necessarily an Android 13 bug at all. Android 13 appears to have improved "Block connections without VPN" to block certain inbound traffic to the base OS outside the VPN which was not previously blocked. It's possible that it's working entirely as intended but that some carriers had a buggy setup that this breaks.

Some users with an app-based VPN with "Always-on VPN" and "Block connections without VPN" are having it unable to work via mobile data on Android 13.

Only happens for ~5 to 10% of people with this setup. We haven't been able to identify a pattern with device, carrier or VPN app. We're investigating whether it's an upstream Android 13 issue and whether it could be caused by any of our changes.

We had reports of this issue for our Alpha and Beta releases for Android 13 but we've still been unable to reproduce the problem and get many inconsistent reports.

https://twitter.com/GrapheneOS/status/1542840552248451074

Latest release of GrapheneOS adds support for one of the killer features we've wanted to ship for a long time: forwarding notifications between user profiles.

Can enable this per-user in Settings ➔ System ➔ Multiple users to forward the notifications. Each user is a separate isolated workspace with separate instances of apps, app data and profile data such as contacts and the user's home directory.

We plan on adding more usability features for user profiles to make using them as isolated workspaces increasingly convenient.

GrapheneOS is now based on Android 12.1.

https://twitter.com/GrapheneOS/status/1501146112538947592

This release needs to go through longer internal testing than usual so it will still be hours before we can start pushing it out via the Beta channel.

It will be a bit delayed for end-of-life Pixel 3 and 3 XL. This release provides the March Android security update.

This also fixes several more security issues which were missed by Android. We've found over a dozen of these missed security patches in the past 6 months. We regularly check to make sure these patches are actually applied.