6 ms·

GrapheneOS blocked exploitation of 3 Android zero-days used by Cellebrite

132 points by akyuu 2y ago

linwangg 2y ago
[flagged]
- protimewaster 2y ago
  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 2y ago
    Play Integrity is DRM masquerading as a security feature. Unfortunately, many app developers care more about the former.
    - protimewaster 2y ago
      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.
      - notpushkin 2y ago
        Because it says “security” and looks good on paper. For some inexplicable reason, many banks don’t seem to care about actual security, even the modern ones. (Shame on you, Revolut)
      - brookst 2y ago
        Your bank loses money when keyloggers/etc are used. Play integrity claims to avoid this problem, and a rooted device with an alternative ROM is a big red flag. There are nuances here and there are probably ways app developers could support legit Graphene but not a malicious fork, but that’s a lot of work and expertise to reach an extra 0.01% of the population.
        protimewaster 2y ago
        I understand the idea, but GrapheneOS doesn't even provide any kind of official support for rooting. It's not that they're checking to see if the device is rooted, they're just checking to see if it has Google's checkmark. Meanwhile, rooted devices can pass Play Integrity (since they can spoof all the necessary bits via root).
        brookst 2y ago
        Isn’t play integrity based on PKI and hardware root of trust? How does a rooted device fake the signed ROM / bootloader / etc?
        protimewaster 2y ago
        I haven't read about it too much since I'm not rooted, but lots of users report being able to use apps that require integrity with various root approaches (e.g., https://www.reddit.com/r/Magisk/comments/19c1dv0/help_can_i_pass_the_playintegrity_strong/ https://www.reddit.com/r/Magisk/comments/19c1dv0/help_can_i_...)
        yjftsjthsd-h 2y ago
        > Your bank loses money when keyloggers/etc are used. Play integrity claims to avoid this problem, and a rooted device with an alternative ROM is a big red flag. Well... no? Maybe a device with things running as root is a yellow flag, but malware isn't going to replace the ROM or install a normal user-controlled root solution. Or put differently, if your "security" system flags the latest version of Lineage OS but doesn't flag a year-old stock ROM with known CVEs, then your system is actively fighting against security.
      - Retr0id 2y ago
        You're not likely to pirate your own banking app, but thieves would love to patch the APK (or OS itself) so that it works "normally" except for skimming off credentials etc. in the background. This is functionally equivalent to what happens in app piracy (or game cheating, etc.), and all the same mechanisms are used to try to prevent it. I don't blame the banking apps, it makes sense given their incentives and constraints. But if Play Integrity existed to serve the user, it would answer only to the user, and not "snitch" the device integrity status to apps and their backends.
  - Hizonner 2y ago
    App developers are going along with it because many of the third-party ROMs so insolently take the view that a user's device should serve the user.
    - brookst 2y ago
      And some of those users are malicious. It’s easier to cut off small populations than to sort out the good ROMs from the evil ones.
      - Hizonner 2y ago
        If your app can be manipulated to your disadvantage by the user, then you are putting undue trust in client-side software, and you need to rearchitect your service. Or, sure, you can stick with your lazy, slipshod design and try to paper it over with (unreliable and stupid) attempts to disempower the user.
        brookst 2y ago
        Security isn’t binary, it’s about layers and probabilities. A client that attests play integrity is less likely to be an attacker than one that isn’t. That doesn’t mean it’s impossible to use an attested device in an attack, or that all non-attested devices are malicious. A good heuristic is that if you find yourself using absolutes and dramatic, insulting language… you do not have a valuable insight about security.
        Hizonner 2y ago
        > Security isn’t binary, it’s about layers and probabilities. A truth frequently abused to excuse obviously bad practices. > A client that attests play integrity is less likely to be an attacker than one that isn’t. A comfortable, yet completely unjustified, assumption.
        protimewaster 2y ago
        > A comfortable, yet completely unjustified, assumption. I agree. Knowledgeable users are passing Play Integrity on rooted devices. The idea that these knowledgeable users who are willing to bypass local security checks are more trustworthy than users who honestly fail the security test feels like a strange stance on security. If you want assurance that your code won't run on modified devices, don't let users run the code at all. Have them come into the bank branch and use hardware that you control.
  - everdrive 2y ago
    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.
  - jeroenhd 2y ago
    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.
- iszomer 2y ago
  Is everyone forgetting that GrapheneOS only runs on one specific brand, namely Google's Pixel line exclusively? - https://grapheneos.org/faq#supported-devices https://grapheneos.org/faq#supported-devices
osy 2y ago
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-cloud-backup 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-sec59b0b31ff/1/web/1 https://support.apple.com/guide/security/secure-enclave-sec5... [3]: https://support.apple.com/guide/security/operating-system-integrity-sec8b776536b/1/web/1 https://support.apple.com/guide/security/operating-system-in... [4]: https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/ https://security.apple.com/blog/towards-the-next-generation-... [5]: https://googleprojectzero.blogspot.com/p/0day.html?m=1 https://googleprojectzero.blogspot.com/p/0day.html?m=1
jeroenhd 2y ago
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.
- deleted 2y ago
  [deleted]
- soulofmischief 2y ago
  For one, Google would have access to less telemetry for ad purposes.
  - gruez 2y ago
    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 2y ago
      Since grapheneos sandboxes everything, including google play, is this still true?
      - aesh2Xa1 2y ago
        I think it is not true. It would help if the GrapheneOS project included some examples of how Google Play is privileged in the standard Android. Google Play Services can access all of the following, for example: clipboard data, network information and connection details, sensor data, the list of installed applications, app usage statistics. You can install the sandbox without granting these permissions (and they are not granted by default).
- 2y ago
deleted 2y ago
[deleted]
warabe 2y ago
As a happy GrapheneOS user, I just want to say thank you to the people behind the project.
judithh 2y ago
[flagged]

132 points by akyuu 2y ago

linwangg 2y ago

[flagged]

protimewaster 2y ago
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 2y ago
  Play Integrity is DRM masquerading as a security feature. Unfortunately, many app developers care more about the former.
  - protimewaster 2y ago
    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.
    - notpushkin 2y ago
      Because it says “security” and looks good on paper. For some inexplicable reason, many banks don’t seem to care about actual security, even the modern ones. (Shame on you, Revolut)
    - brookst 2y ago
      Your bank loses money when keyloggers/etc are used. Play integrity claims to avoid this problem, and a rooted device with an alternative ROM is a big red flag. There are nuances here and there are probably ways app developers could support legit Graphene but not a malicious fork, but that’s a lot of work and expertise to reach an extra 0.01% of the population.
      - protimewaster 2y ago
        I understand the idea, but GrapheneOS doesn't even provide any kind of official support for rooting. It's not that they're checking to see if the device is rooted, they're just checking to see if it has Google's checkmark. Meanwhile, rooted devices can pass Play Integrity (since they can spoof all the necessary bits via root).
        brookst 2y ago
        Isn’t play integrity based on PKI and hardware root of trust? How does a rooted device fake the signed ROM / bootloader / etc?
        protimewaster 2y ago
        I haven't read about it too much since I'm not rooted, but lots of users report being able to use apps that require integrity with various root approaches (e.g., https://www.reddit.com/r/Magisk/comments/19c1dv0/help_can_i_pass_the_playintegrity_strong/ https://www.reddit.com/r/Magisk/comments/19c1dv0/help_can_i_...)
      - yjftsjthsd-h 2y ago
        > Your bank loses money when keyloggers/etc are used. Play integrity claims to avoid this problem, and a rooted device with an alternative ROM is a big red flag. Well... no? Maybe a device with things running as root is a yellow flag, but malware isn't going to replace the ROM or install a normal user-controlled root solution. Or put differently, if your "security" system flags the latest version of Lineage OS but doesn't flag a year-old stock ROM with known CVEs, then your system is actively fighting against security.
    - Retr0id 2y ago
      You're not likely to pirate your own banking app, but thieves would love to patch the APK (or OS itself) so that it works "normally" except for skimming off credentials etc. in the background. This is functionally equivalent to what happens in app piracy (or game cheating, etc.), and all the same mechanisms are used to try to prevent it. I don't blame the banking apps, it makes sense given their incentives and constraints. But if Play Integrity existed to serve the user, it would answer only to the user, and not "snitch" the device integrity status to apps and their backends.
- Hizonner 2y ago
  App developers are going along with it because many of the third-party ROMs so insolently take the view that a user's device should serve the user.
  - brookst 2y ago
    And some of those users are malicious. It’s easier to cut off small populations than to sort out the good ROMs from the evil ones.
    - Hizonner 2y ago
      If your app can be manipulated to your disadvantage by the user, then you are putting undue trust in client-side software, and you need to rearchitect your service. Or, sure, you can stick with your lazy, slipshod design and try to paper it over with (unreliable and stupid) attempts to disempower the user.
      - brookst 2y ago
        Security isn’t binary, it’s about layers and probabilities. A client that attests play integrity is less likely to be an attacker than one that isn’t. That doesn’t mean it’s impossible to use an attested device in an attack, or that all non-attested devices are malicious. A good heuristic is that if you find yourself using absolutes and dramatic, insulting language… you do not have a valuable insight about security.
        Hizonner 2y ago
        > Security isn’t binary, it’s about layers and probabilities. A truth frequently abused to excuse obviously bad practices. > A client that attests play integrity is less likely to be an attacker than one that isn’t. A comfortable, yet completely unjustified, assumption.
        protimewaster 2y ago
        > A comfortable, yet completely unjustified, assumption. I agree. Knowledgeable users are passing Play Integrity on rooted devices. The idea that these knowledgeable users who are willing to bypass local security checks are more trustworthy than users who honestly fail the security test feels like a strange stance on security. If you want assurance that your code won't run on modified devices, don't let users run the code at all. Have them come into the bank branch and use hardware that you control.
- everdrive 2y ago
  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.
- jeroenhd 2y ago
  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.
iszomer 2y ago
Is everyone forgetting that GrapheneOS only runs on one specific brand, namely Google's Pixel line exclusively? - https://grapheneos.org/faq#supported-devices https://grapheneos.org/faq#supported-devices

osy 2y ago

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-cloud-backup 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-sec59b0b31ff/1/web/1 https://support.apple.com/guide/security/secure-enclave-sec5... [3]: https://support.apple.com/guide/security/operating-system-integrity-sec8b776536b/1/web/1 https://support.apple.com/guide/security/operating-system-in... [4]: https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/ https://security.apple.com/blog/towards-the-next-generation-... [5]: https://googleprojectzero.blogspot.com/p/0day.html?m=1 https://googleprojectzero.blogspot.com/p/0day.html?m=1

jeroenhd 2y ago

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.

deleted 2y ago
[deleted]
soulofmischief 2y ago
For one, Google would have access to less telemetry for ad purposes.
- gruez 2y ago
  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 2y ago
    Since grapheneos sandboxes everything, including google play, is this still true?
    - aesh2Xa1 2y ago
      I think it is not true. It would help if the GrapheneOS project included some examples of how Google Play is privileged in the standard Android. Google Play Services can access all of the following, for example: clipboard data, network information and connection details, sensor data, the list of installed applications, app usage statistics. You can install the sandbox without granting these permissions (and they are not granted by default).
2y ago

deleted 2y ago

[deleted]

warabe 2y ago

As a happy GrapheneOS user, I just want to say thank you to the people behind the project.

judithh 2y ago

[flagged]