Titan_M2 Will GOS ever stand against softwares like Pegasus and such even when GOS will use its own hardware?

    @

    PMUSR @[deleted]

    If you look at it realistically, there will probably always be ways and means to compromise a smartphone - if only an actor uses enough resources. It's more a matter of raising the bar significantly.

    If you haven't heard of it, I highly recommend this interview from The Hated One with a GrapheneOS security researcher. It doesn't answer your question specifically, but it goes in that direction. From about minute 47, your question is addressed in general, later Gabe - that's the name of the security researcher - also talks about MTE.

      Murcielago so I've heard of Pegasus before but don't know much about it.
      Is that software pretty much able to hack pixels with graphene os now? Or is it still difficult?

        L8437 Pegasus itself can't hack anything. It's just the payload that is deployed after access has been gained to a device. It has to be combined with a complicated exploit chain. These can often be worth millions of dollars and are mostly by nation state actors and other advanced adversaries. Companies like Zerodium aggregate chains of zero-day exploits and then sell them to companies like the NSO Group, the makers of Pegasus, for astronomical sums of money, often millions of dollars. It's a very dirty market. It's not really possible to safely assume what devices/software can currently be exploited by Pegasus or any advanced malware, it depends on what zero-day exploits they currently know about. These zero-days are pretty much single-use though. After an exploit gets deployed, it's likely for the device to be sent to an organization like Citizen Lab where it is closely examined, the malware is inspected and the vulnerability is reported to the vendor of the device/software and fixed. The Hated One made a great video about malware like Pegasus and zero-day exploits in general: https://piped.video/watch?v=LOPWNJxdxWY
        You can also check out the Pegasus Project, it's a research group consisting of journalists in various countries who try to uncover as much information about Pegasus as possible.

          Velocity9490 Pegasus itself can't hack anything. It's just the payload that is deployed after access has been gained to a device.

          It’s the commercial name of the all around remote phone surveillance as-a-service, not just the payload. It includes exploits too but the customer does not get access to them, only access is a terminal when to input phone numbers of targets and monitor for data visualization.

          Velocity9490 These zero-days are pretty much single-use though.

          Just a single target? I don’t think so.

          Velocity9490 After an exploit gets deployed, it's likely for the device to be sent to an organization like Citizen Lab

          If they get detected.

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

          We've been making more progress on hardware memory tagging support for Pixel 8 and Pixel 8 Pro. Our initial hardened_malloc integration has no noticeable overhead in fastest asynchronous mode and the asymmetric mode is lower overhead than legacy mitigations like stack canaries.

          Asynchronous is very fast but can be bypassed via races. Synchronous is very high overhead and aimed at debugging. It's still much faster than HWAsan (based on Top Byte Ignore) and especially ASan. Asymmetric is nearly as fast as asynchronous and as secure as synchronous.

          There isn't any clear way to bypass asynchronous wrote checks for the asymmetric mode since they're checked immediately on reads and system calls. io_uring might be able to bypass it, but it's not relevant since it's only allowed for 2 core SELinux domains (fastbootd, snapuserd).

          We plan to enable memory tagging by default in asymmetric mode for the whole base OS including system apps. For user installed apps, our plan is to enable it by default for app processes without their own native code. It will be opt-in for apps with native code for compatibility.

          Memory tagging is going to be a huge game changer and GrapheneOS will be on the leading edge deploying it. Stock Pixel OS has it as a developer option which isn't usable in practice since it breaks far too much. The implementation is also much less powerful than hardened_malloc.

          Initial hardened_malloc implementation sets random tags for each 128k byte and below allocation. It excludes tags of adjacent allocations and reserves a tag for free allocations. It fully prevents sequential overflows as a vulnerability class and freed memory can't be accessed.

          Use-after-free is detected until another allocation is made in the same slot with the same random tag chosen for it. hardened_malloc already defends this by quarantining freed allocations by default. They go through a First-In-First-Out ring buffer and a swap with a random array.

          Arbitrary read/write via buffer overflows are caught by the random tags. They're unfortunately currently only 4 bit, but a future architecture revision could raise them to 8 bit. CFI, PAC, etc. only try to defend specific targets and don't work well against arbitrary read/write.

          Nearly all remote code execution vulnerabilities in the OS are memory corruption bugs: either use-after-free or buffer overflows. The majority involves the malloc heap and the rest mostly involves the stack which could also use MTE-based defenses to replace SSP + ShadowCallStack.

          Most apps are a similar story as the base OS. Chromium has pervasive type confusion bugs which MTE doesn't explicitly protect against, but CFI and PartitionAlloc already do. Vanadium already has CFI enabled unlike Android Chrome, but there are more CFI features we need to enable.

          After the initial hardened_malloc memory tagging implementation is shipped and enabled by default for the OS and many user installed apps, we can consider using more selection of tags (see https://github.com/GrapheneOS/hardened_malloc/blob/main/README.md#memory-tagging). We can also consider using MTE beyond inside hardened_malloc.

            For L8437 and others who may not fully understand that concepts explained in the above tweets (which is completely understandable), I think this very short tweet by @GrapheneOS sums it up nicely:

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

            GrapheneOS will be getting massive improvements to our defenses against remote exploitation. It's going to significantly widen the security advantage over an iPhone or Pixel until they get default enabled memory tagging support. It's going to be a serious game changer.

            [deleted] Nothing is bulletproof. Not GrapheneOS, or anything else. Anyone trying to sell you on a 100% guarantee is being dishonest. As mentioned in the GrapheneOS documentation:

            [...] The next line of defense is preventing an attacker from exploiting a vulnerability, either by making it impossible, unreliable or at least meaningfully harder to develop.

            What MTE brings is substantial security improvements. The project claims that it is the biggest security feature being shipped since the project started in 2014. It really is quite significant.

            GrapheneOS already heavily focused on defending against exploitation of unknown vulnerabilities, which is explained here:

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

            MTE will significantly strengthen GrapheneOS' defenses and will raise the bar for exploitation even further.

              Initial hardware memory tagging support now available for Pixel 8 and Pixel 8 Pro in the latest release:

              https://grapheneos.org/releases#2023103000

              • add infrastructure for hardware memory tagging support
              • hardened_malloc: add support for hardware memory tagging launched with the ARMv9 cores on the Pixel 8 and Pixel 8 Pro
              • Settings: enable memory tagging toggle at Settings ➔ Security ➔ More security settings ➔ Advanced memory protection beta on supported devices (Pixel 8 and Pixel 8 Pro)
              • Pixel 8, Pixel 8 Pro: enable memory tagging support for everything built by GrapheneOS (other than Vanadium, since Chromium currently disables it) and also user installed apps without native libraries (will be expanded to Vanadium later along with the option to use it for all user installed apps)
              • Pixel 8, Pixel 8 Pro: use asymmetric memory tagging mode on all cores to provide much higher security than asynchronous mode without much more overhead unlike the very expensive synchronous mode without any clear security benefits over asymmetric

              From what I've read it sounds like MTE is being used to protect userspace, not the kernel itself. I read this blog post from Google Project Zero that talks about issues with protecting the kernel itself with MTE: https://googleprojectzero.blogspot.com/2023/08/mte-as-implemented-part-3-kernel.html

              Out of curiosity, is this something the GrapheneOS team is looking at? It sounds like a lot of upstream work would be needed before this becomes a robust mitigation, but unless kernel MTE failures occur in practice, it seems like it would be worth having in the kernel as a defense in depth, even with the issues described in that blog post.

                PolarOctopus We've started with userspace heap MTE which is now available but not yet enabled by default, which we want to do. We'll investigate userspace stack MTE next. Kernel doesn't really have proper MTE support but rather includes it as part of kasan and it's designed more as a debugging feature than a hardening feature so it would need a major overhaul.

                This is great. I see that it's labelled as beta. Are there any reasons for problems to arise at the moment? I'm not sure if I should hold back activating it for now.

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

                GrapheneOS now has hardware memory tagging support in our Stable channel. Memory tagging greatly improves protection against targeted attacks. Thanks to hardware support on the Pixel 8 and Pixel 8 Pro, it's extremely low overhead despite the massive benefits it's able to provide.

                GrapheneOS users on the Pixel 8 and Pixel 8 Pro can enable memory tagging via Settings ➔ Security ➔ More security settings ➔ Advanced memory protection beta on supported devices. We'll be enabling it by default soon since we have a solid approach to preserve app compatibility.

                We integrated it into hardened_malloc where it's able to provide stronger security properties than the experimental stock OS implementation.

                Our current toggle enables it for everything other than Vanadium, vendor executables and user installed apps bundling native libraries.

                We'll be enabling memory tagging support for Vanadium by default via the standard Chromium implementation.

                For the near future, we'll be leaving memory tagging disabled by default for user installed apps bundling native libraries to avoid introducing a new compatibility issues.

                It will be possible to enable memory tagging for all user installed apps with the ability to opt-out for specific apps where it causes issues. We want to eventually have it globally enabled by default, but we expect it to uncover a lot of issues hardened_malloc hasn't before.

                It's also possible to use MTE for protecting from stack buffer overflows and use-after-scope by aligning and tagging variables with an escaping pointer. LLVM has an implementation of this and we've confirmed it works but it may not be optimized enough to enable it quite yet.

                When fully integrated into the compiler and each heap allocator, MTE enforces a form of memory safety. It detects memory corruption as it happens. 4 bit tags limit it to probabilistic detection for the general case, but deterministic guarantees are possible via reserving tags.

                In hardened_malloc, we deterministically prevent sequential overflows by excluding adjacent tags. We exclude a tag reserved for free tag and the previous tag used for the previous allocation in the slot to help with use-after-free detection alongside FIFO and random quarantines.

                MTE support for protecting the Linux kernel isn't enabled yet, but we can likely enable that by default too. However, it's currently part of kasan and is more oriented towards debugging than hardening. It's not entirely clear that enabling it in the current state is a good idea.

                What mode is recommended for highest security?

                  8 days later

                  PMUSR synchronous, it seems, but that has high overhead. From everything I've read above, asymmetric mode seems to have as high of security as synchronous mode, while only requiring the overhead about of asynchronous mode (lower security but lower overhead).

                  That us, if I've understood the above correctly, someone please correct me if I'm wrong in any way! I'm really looking forward to my Pixel 8 Pro mostly so I can enjoy the benefits of defenses against 70% of common security vulnerabilities!

                  10 days later

                  I just got my pixel 8 and installed GrapheneOS on it, unfortunately I cannot find the mentioned MTE option under security -> more security settings. Do I need to enable anything on a fresh install to get it?

                    Is there an easy way to see if it was triggered, like a crash log monitor? For Linux and kasan you can look into journalctl for the backtrace, would be nice to have a way to monitor crash logs in an easy way on the device.