GrapheneOS blocked exploitation of 3 Android zero-days used by Cellebrite
32 comments
·March 1, 2025jeroenhd
AlgebraFox
Google is afraid of small performance penalty. GrapheneOS offers knobs to control compatibility. You can always turn off individual protections, in case an app could not function under default settings.
null
Arnt
A friend of mine who ran customer support said: if you break some app with av upgrade, you get a shitstorm.
brightball
I always wonder if not doing this is a carryover from spinning disks where the performance penalty was a big deal.
The other reason for not doing it by default is probably to enable digital forensics for people who don’t know any better.
null
soulofmischief
For one, Google would have access to less telemetry for ad purposes.
gruez
Google already gets all the telemetry it needs through play services and all the other SDKs they offer (eg. firebase). It doesn't need to search through freed memory.
snapplebobapple
Since grapheneos sandboxes everything, including google play, is this still true?
linwangg
This is yet another example of how security-focused OSes like GrapheneOS are outpacing stock Android when it comes to real-world threat mitigation. If Cellebrite and similar forensics tools can still exploit mainstream Android devices, how much trust should we place in Google's security model? Does this suggest that hardened user-controlled OSes are the only real solution for privacy-conscious users?
protimewaster
Meanwhile, apps are starting to block GrapheneOS (and others), because GrapheneOS doesn't pass the Play Integrity "security" test. At the same time, stock devices that haven't received security updates for 5 years (and are vulnerable to known exploits) do pass Play Integrity.
Google is basically using Play Integrity to limit the functionality of Android variants like GrapheneOS (while pretending it's about security), and app developers are, for some reason, happily going along with it.
Retr0id
Play Integrity is DRM masquerading as a security feature. Unfortunately, many app developers care more about the former.
protimewaster
I kinda understand it if a developer actually wants DRM. But why does my bank care to use it? I'm not likely to pirate my banking app.
jeroenhd
Security, from an app developer perspective, isn't necessarily about the user getting exploited. It's also about protecting the app's interests.
Phones rooted by malware will fail Play Integrity, if checked well (hardware verification). For apps that are on the hook for paying for users' mistakes (banking apps, for instance), that makes a lot of sense.
Games care more about preventing cheaters than about users getting their Bluetooth stack getting exploited.
Remote attestation like Play Integrity can be used for legitimate security purposes, like in managed MDM settings, but it's not just about security.
everdrive
This is very well said. Every time the subject of smartphones comes up, people will claim there are workarounds to the privacy, security, repair-ability, or usability issues. These arguments have some merit, but these workarounds are almost always very fragile, tenuous, and completely out of reach for most normal users. If you come to rely on these workarounds, you'll be playing a game of cat and mouse for years as Google and Apple find different ways to indirectly ruin your workflow.
null
osy
Until basic features like cloud backup/restore[1] works on GrapheneOS, they are irrelevant when talking about sophisticated targeted attacks. Your random journalist uncovering corruption in Saudi Arabia doesn't have the time to figure out how to flash a new ROM image, sideload Google apps, etc. GrapheneOS is great for privacy conscious technical users who wishes to use Android. For everyone else, iOS is far more secure OOB than popular Android phones and iOS with Lockdown mode beats GrapheneOS and is a single journo friendly toggle.
[1]: https://discuss.grapheneos.org/d/15370-restore-from-google-c...
For all the drones in the replies repeating the same talking point over and over again you fail to address the criticism: GrapheneOS is not usable for non-technical users.
Now in terms of security/privacy, anyone who is talking about "look at the public exploits" is missing the point because nobody is attacking GrapheneOS for the same reason why nobody attacks macOS. Yes there is some marginal security difference but it's mostly because nobody who matters uses it. (I'm sorry but you, random SV tech worker who knows about GrapheneOS doesn't count.)
If you want some examples of just a _few_ things iOS does that nobody else does:
1. Secure nonvolatile storage[2]: On the most recent iOS devices there is an off chip custom dedicated smart card like device that manages passcode attempts. It's set up in a way that even if you completely hack the storage IC + SEP you cannot get any info on the passcode and still need to brute force on device. The only comparable feature is the StrongBox implemented either with an off the shelf SE (huge attack surface) or Titan M on latest Pixel phones which if hacked + TEE hack (also huge attack surface) gains you offline brute force.
2. Trusted Execution Monitor[3]: Even if you get kernel data rw access via exploit, you cannot kernel code execution because of hardware locks. You cannot even get EL0 userland execution because of the dedicated TXM which monitors the page tables. The only comparable feature is Samsung Knox which does monitor based page table management but done much worse and is full of holes. Pixel has nothing. Neither of them have any hardware locks on kernel code.
3. kalloc_type[4]: in addition to the standard slab based heap isolation that Linux also provides, XNU also promises never to reuse a virtual address for objects of different type completely defeating cross-cache based attacks. Types are also tagged with metadata showing which fields in a struct are pointers and which are numerical data such that the two will never overlap in random cases of slab sharing.
There's tonnes more but there's no point listing them all. As someone who've researched both iOS and Android attacks (and you can ask anyone in the industry who've done the same), iOS security is far ahead. GrapheneOS only provides mitigations that bring Android up to par in many areas (caveat: MTE is coming soon on iOS but is current shipped in a performance regressive way in GrapheneOS and a don't-enable-me-but-we-technically-shipped-it developer toggle on Pixels).
Also: Android attacks are far and plenty. You don't hear about most of them because they're not newsworthy because they're just dumb vendor bugs and nobody expects Android to be more secure because they don't market it that way. If you want a glimpse of what in-the-wilds are publicly disclosed for both iOS and Android, look at P0's list[5] especially for recent years (2024-2025).
Again none of this matters because the bigger argument is that GrapheneOS is not user friendly and therefore it's irrelevant how powerful they defend against the 0.01% attacker who targets specific people.
[2]: https://support.apple.com/guide/security/secure-enclave-sec5...
[3]: https://support.apple.com/guide/security/operating-system-in...
[4]: https://security.apple.com/blog/towards-the-next-generation-...
ibeff
Do you have a source that iOS Lockdown Mode protects against Cellebrite? Because Cellebrite boasts they can extract data from latest iOS versions and does not even mention Lockdown Mode as an obstacle in their documentation: https://stacker.news/items/617666
Meanwhile, Cellebrite is unabe to extract data from newer Pixel phones with GrapheneOS: https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...
soulofmischief
That is simply wishful thinking. iPhones have had plenty of embarrassing, severe exploits used in the field, such as zero-click RCEs https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer...
zuhsetaqi
> iOS is far more secure OOB than popular Android forks and iOS with Lockdown mode beats GrapheneOS
Do you have a source for this?
protimewaster
I'm curious about this too. AFAIK the most recent leaked Cellebrite docs indicated that GOS can't be broken into, and I dunno how iOS could be more secure than that.
switch007
AIUI Lockdown Mode doesn't stop e.g. Cellebite. (Lockdown Mode was introduced as an answer to e.g. Pegasus)
Cloud backup I imagine is seen as an anti-feature.
Nobody _needs_ to side load Google apps. That's the whole point - you don't have to use anything Google.
And I imagine many journalists do indeed take couple of hours to install GrapheneOS as it's a valuable tool of the trade.
Believing iOS is the most secure is just buying into their marketing. Sorry
AlgebraFox
GrapheneOS team has done an amazing job building a rock solid OS for mobile. But because it does not have the feature you need, doesn't mean it's useless for rest of us. I use it everyday for it's privacy and security features. Your argument is really weak. What does cloud backup has to do with it protecting from zero days?
eloeffler
I've just recently switched to GrapheneOS and I must say it has been very convenient. That is, coming from the hassle of flashing LineageOS to Samsung devices.
Obviously, buying a device and using it as it is will always be the easiest path and I would have recommended Apple to anyone looking for this until this week, when Apple pulled the E2E feature from British phones.
So GrapheneOS is the only reasonable option left that I know of.
Installing sandboxed Google Play (no sideloading needed) from the Graphene App Store is a breeze by the way. It's right there after installing the OS.
And Pixel devices don't try to keep you from replacing the stock rom, you don't lose your warranty doing it. And there is a browser-based installer that gets rid of the need of using command lines.
Klickibunti, as German GUI-defiers would say.
loufe
This is such a shallow take. There is little learning involved in setting up GrapheneOS, especially if someone a little more techy lends a hand. I'd argue I need less of my tech background and run into far less hiccups than my typical linux desktop install experience. What's especially frustrating about this, is there's no need to sideload apps, or anything you're implying. I can use any cloud backup app I want, there's a built-in installer for a sandboxed Google Play Store, and generally you have almost no discernible usability differences vs stock.
fluidcruft
Probably GrapheneOS is too small a target for Cellebrite to bother focusing on. In the mean time, I would expect Google to fix the 0 days and we move on.
That's just to say that in my ranking of Cellebrite-using threat actors we're all ultimately just meat popsicles anyway.
I can't imagine Google doesn't know about the techniques Graphene employs or how to enable them themselves. What are the downsides to offering these mitigations? Is the performance impact of zeroing freed memory that high? Does offering a setting to block USB devices by default impact the user experience that badly?
I kind of want to try GrapheneOS but because unlike other ROMs they care about security and not so much compatibility, most root-avoiding/ROM-block-avoiding features just aren't available on it.