Live data from Hacker News

Memory Integrity Enforcement

security.apple.com

81–90 of 259 posts

Re: Memory Integrity Enforcement

#81
post #23

Earlier quoted context omitted.

Saying "never" is too bold. But it's definitely getting immensely difficult. There are still plenty of other flaws besides memory unsafety to exploit. I doubt that we'll see like a formally proven mainstream OS for a long time.

Those flaws get harder the more restricted devices are.

Depends. If "restriction" means "complexity" then you may end up with scenarios like the BlastDoor vulns (eg. FORCEDENTRY).

Re: Memory Integrity Enforcement

#82
post #6

Earlier quoted context omitted.

Look, I’m an iOS user but this seems like flame-bait to me without any technical details. I’ve seen a lot of Google blog posts about security improvements over the years so that seems like a very sweeping assertion if you’re not going to support it.

Recent discussion on 90-day embargo for security updates, https://news.ycombinator.com/item?id=45158523

That’s potentially substantial but I note that Graphene specifically rejected the framing:

https://xcancel.com/GrapheneOS/status/1964757878910136346

Re: Memory Integrity Enforcement

#83

> There has never been a successful, widespread malware attack against iPhone. The only system-level iOS attacks we observe in the wild come from mercenary spyware ... to target a very small number of specific individuals and their devices. Although the vast majority of users will never be targeted in this way.. Correct me if I'm wrong, but the spyware that has been developed certainly could be applied at scale at th…

Neither Apple or Google truly knows how widespread attacks on their products have been despite portraying it as if they have perfect insight into it. They're claiming to know something they cannot. GrapheneOS has published leaked data from exploit developers showing they're much more successful at exploiting devices and keeping up with updates than most people believe. We have access to more than what we've published, since we don't publish it without multiple independent sources to avoid leaks being identified. These tools are widely available, and it cannot be generally known when they're used whether it's data extraction or remote exploitation. Catching exploits in the wild is the exception to the rule, otherwise exploit development companies would have a much harder job needing to keep making new exploits after they're heavily used. They wouldn't value a single exploit chain nearly as much as they do if it stopped working after it was used 50k times. Law enforcement around the world has access to tools like Cellebrite Premium which are used against many people crossing borders, at protests, etc. That is usage at scale. There's far less insight into remote exploits which don't have to be distributed broadly to be broadly used.

Re: Memory Integrity Enforcement

#84
post #79

> There has never been a successful, widespread malware attack against iPhone. The only system-level iOS attacks we observe in the wild come from mercenary spyware ... to target a very small number of specific individuals and their devices. Although the vast majority of users will never be targeted in this way.. Correct me if I'm wrong, but the spyware that has been developed certainly could be applied at scale at th…

Maybe, maybe not. But it seems fair to point out. Certainly if it was as exposed as, say, Windows, then there would have been many.

I mean, if you read the exploit chains, they apply to all iPhones and are wormable.

Re: Memory Integrity Enforcement

#85

With EU chat control, the state will be on my device, having access to everything they want, decide what I can and cannot do. Once Google forces WEI on us, the whole web will get locked down. And secure boot and now MIE will make sure we can never take back our freedom.

That is, unless we balkanize our systems and services.

> That is, unless we balkanize our systems and services.

...all the way back to pen and paper

Re: Memory Integrity Enforcement

#86
post #38

> Google took a great first step last year when they offered MTE to those who opt in to their program for at-risk users. But even for users who turn it on, the effectiveness of MTE on Android is limited by the lack of deep integration with the operating system that distinguishes Memory Integrity Enforcement and its use of EMTE on Apple silicon. > With the introduction of the iPhone 17 lineup and iPhone Air, we’re exc…

Apple has been working on this for years. It's not like they started thinking about memory tagging when Daniel decided to turn it on in GrapheneOS.

GrapheneOS made our own integration of MTE for hardened_malloc and has done significant work on it. It wasn't simply something we turned on. ARM designed and built the feature which was made available in Cortex cores. Google's Tensor uses standard Cortex cores so unlike Qualcomm they didn't need to make their own implementation. Google integrated it into Android and did some work to make it available on Pixels along with fixing many bugs it uncovered, although definitely not all of them. We had to fix many of the issues. Apple had to make their own hardware implementation because they have their own cores, which Qualcomm finally got done too.

Pixels are not the only Android devices with MTE anymore and haven't been for a while. We've tried it on a Samsung tablet which we would have liked to be able to support if Samsung allowed it and did a better job with updates.

GrapheneOS is not a 1 person project and not a hobby project. I wasn't the one to implement MTE for hardened_malloc and have not done most of the work on it. The work was primarily done by Dmitry Muhomor who is the lead developer of GrapheneOS and does much more development work on the OS than I do. That has been the case for years. GrapheneOS is not my personal project.

We've done a large amount of work on it including getting bugs fixed in Linux, AOSP and many third party apps. Our users are doing very broad testing of Android apps with MTE and reporting issues to developers. There's a specific crash reporting system we integrated for it to help users provide usable information to app developers. The hard part is getting apps to deal with their memory corruption bugs and eventually Google is going to need to push for that by enabling heap MTE by default at a new target API level. Ideally stack allocation MTE would also be used but it has a much higher cost than heap MTE which Apple and Google are unlikely to want to introduce for production use.

Android apps were historically largely written in Java which means they have far fewer memory corruption bugs than desktop software and MTE is far easier to deploy than it otherwise would be. Still, there are a lot of native libraries and certain kinds of apps such as AAA games with far more native code have much bigger issues with MTE.

Re: Memory Integrity Enforcement

#88

> In 2018, we were the first in the industry to deploy Pointer Authentication Codes (PAC) in the A12 Bionic chip, to protect code flow integrity in the presence of memory corruption. The strong success of this defensive mechanism in increasing exploitation complexity left no doubt that the deep integration of software and hardware security would be key to addressing some of our greatest security challenges. There hav…

To be fair, they didn't claim it to be a meaningful attack deterrent. They said "success...in increasing exploitation complexity".

Sure, the whole sentence is a bit of a weird mess. Paraphrased: it made exploits more complex, so we concluded that we needed a combined SW/HW approach. What I read into that is that they're admitting PAC didn't work, so they needed to come up with a new approach and part of that approach was to accept that they couldn't do it using either SW or HW alone.

Then again... I don't know much about PAC, but to me it seems like it's a HW feature that requires SW changes to make use of it, so it's kind of HW+SW already. But that's a pointless quibble; EMTE employs a lot more coordination and covers a lot more surface, iiuc.

Re: Memory Integrity Enforcement

#89
post #74

Earlier quoted context omitted.

I think I broadly agree with you. IMO tagging is practically much, much more valuable than capabilities systems modeled like CHERI.

Yes, but CHERI opens whole new system design possibilities, including things like ultra-cheap intra -address-space security boundaries. See https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201607... > We have used CHERI’s ISA facilities as a foundation to build a software object-capability model supporting orders of magnitude greater compartmentalization performance, and hence granularity, than current designs.…

Yes, but this breaks mirror mappings.

Re: Memory Integrity Enforcement

#90
post #83

> There has never been a successful, widespread malware attack against iPhone. The only system-level iOS attacks we observe in the wild come from mercenary spyware ... to target a very small number of specific individuals and their devices. Although the vast majority of users will never be targeted in this way.. Correct me if I'm wrong, but the spyware that has been developed certainly could be applied at scale at th…

Neither Apple or Google truly knows how widespread attacks on their products have been despite portraying it as if they have perfect insight into it. They're claiming to know something they cannot. GrapheneOS has published leaked data from exploit developers showing they're much more successful at exploiting devices and keeping up with updates than most people believe. We have access to more than what we've published…

Apple and Google have access to similar or more information than you do, they just don't publish it for similar reasons.
Post reply on HN