September 2024 Android Security Bulletin includes a patch for the wipe bypass we reported: CVE-2024-32896. It's actively exploited by forensic companies across devices. Pixels patched it in June 2024...

September ASB:
June PUB: source.android.com/docs/security/…
source.android.com/docs/security/… We reported several vulnerabilities exploited by forensic companies in January 2024. We proposed implementing firmware reset attack mitigation and wipe-without-reboot. Pixels shipped reset attack mitigation in April 2024 and also a firmware mitigation making wipe bypasses harder.

This is a fake story. Turns out that getting security information from the CISO of a mass surveillance company trying to build a dystopian police state providing police with "predictive policing" software largely based on racial stereotypes is a bad move.

https://x.com/cryps1s/status/1824077327577591827

Trail of Bits iVerify EDR product runs in the standard app sandbox on iOS and Android. It can hardly do anything beyond static scanning of APKs. It's a crippled antivirus app marketed as detecting sophisticated attackers. It's a scam and Trail of Bits has lost all credibility.

Wired was manipulated into spreading misinformation to market Palantir and iVerify by misrepresenting a vulnerability in a disabled demo app as being a serious problem which could be exploited in the real world. They should retract the article but won't.

wired.com/story/google-a… iVerify are scammers and anyone paying them money should rapidly stop doing it and remove their malware from their devices. The real security risk is giving remote code execution on your devices to one of these sketchy EDR companies lying about their capabilities and discoveries.

Here's the Cellebrite Premium 7.69.5 iOS Support Matrix from July 2024.

404media recently published an article based on the same April 2024 docs we received in April and published in May. Many tech news sites including 9to5Mac made incorrect assumptions treating that as current.



Here's the Cellebrite Premium 7.69.5 Android Support Matrix from July 2024 for Pixels. They're still unable to exploit locked GrapheneOS devices unless they're missing patches from 2022. A locked GrapheneOS device also automatically gets back to BFU from AFU after 18h by default.

@Parallel_Comms @utdream CalyxOS rolls back security a fair bit and doesn't provide comparable privacy or security features to GrapheneOS. It is not a hardened OS but rather somewhat anti-hardened. Their focus is marketing and bundling party apps and services, often with problematic privileged access. @Parallel_Comms @utdream CalyxOS lags a bit behind on updates and misleads users about the security patches and privacy/security they offer. All their release notes have inaccurate claims about it, and they copied setting an inaccurate security patch level from LineageOS among other problems from there.

Unplugged are a recent entry in the crowded space of selling insecure hardware with significantly worse privacy and security than an iPhone as highly private and secure. Bottom of the barrel MediaTek device with outdated AOSP is worse than status quo. All marketing, no substance. As part of marketing their products, Unplugged are spreading unsubstantiated spin and misinformation about GrapheneOS and the much more secure hardware we target. We've been aware of it for a while but chose not to respond to it until they began doing it in direct response to us.

@davidbombal This video has major inaccuracies. CalyxOS always uses multiple Google services and gives them extensive privileged access within the OS. CalyxOS has far more limited app compatibility than GrapheneOS, and their approach to compatibility comes a high security and privacy cost. @davidbombal GrapheneOS provides far broader app compatibility via our sandboxed Google Play compatibility layer. It also has a much easier installation process. It's completely backwards to say that GrapheneOS is harder to adopt. What's the basis for making those statements about GrapheneOS?

XRY and Cellebrite say they can do consent-based full filesystem extraction with iOS, Android and GrapheneOS. It means they can extract data from the device once the user provides the lock method, which should always be expected. They unlock, enable developer options and use ADB. Cellebrite's list of capabilities provided to customers in April 2024 shows they can successfully exploit every non-GrapheneOS Android device brand both BFU and AFU, but not GrapheneOS if patch level is past late 2022. It shows only Pixels stop brute force via the secure element.

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.