Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory Integrity Enforcement

security.apple.com

Post reply on HN
Print view View original

101–110 of 259 posts

Re: Memory Integrity Enforcement

#101

Post by strcat »

ysnp wrote: post #53
saagarjha wrote: post #47

Earlier quoted context omitted.

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.

I didn't mean to imply Apple (and Google) hadn't been spearheading multi-year efforts to ship this in collaboration with Arm, I regret a little that it came across that way. Just that it would be nice to see production use of it acknowledged even just as a passing comment. As an outsider I am quite ignorant to what security developments these companies are considering and when the trade-offs are perhaps too compromis…

ARM largely built and shipped it on their own. Cortex cores were the first real world implementation. Pushing ARM to care about it as a security feature instead of only a bug finding feature is something Apple and Google are probably responsible for doing. Pixels are not the only Android devices making MTE but were the first to take advantage of the CPU support by actually setting it up and making it available for use. There are other Android devices doing that now too.

Qualcomm has to make their own implementation which has significantly delayed widespread availability. Exynos and MediaTek have it though.

Re: Memory Integrity Enforcement

#102

Post by strcat »

rdtsc wrote: post #29

1988 called and wants it memory tagging back https://www.devever.net/~hl/ppcas ! But yeah this was support for a the longest time by IBM basically. It's nice to see it's getting more widespread.

SPARC ADI was a predecessor to ARM MTE. ARM MTE has been available and used in production for several years now. ADI is also 4 bit but with 64 byte granularity rather than 16 byte.

Re: Memory Integrity Enforcement

#103

Post by strcat »

saagarjha wrote: post #90
strcat wrote: post #83

Earlier quoted context omitted.

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.

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

If that's the case, then many of their public statements about this are extraordinarily dishonest. There are widespread exploits targeting Safari, Chrome, iOS and Android. These are not only rare attacks targeting people heavily sought out by governments, etc. They do not have nearly as much visibility into it as they make it seem.

Re: Memory Integrity Enforcement

#104

Post by heavyset_go »

gjsman-1000 wrote: post #8

I think hackers are not ready for the idea that unhackable hardware might actually be here. Hardware that will never have an exploit found someday, never be jailbroken, never have piracy, outside of maybe nation-state attacks. Xbox One, 2012? Never hacked. Nintendo Switch 2, 2025? According to reverse engineers... flawlessly secure microkernel and secure monitor built over the Switch 1 generation. Meanwhile NVIDIA's…

I think the nature of the scene changed and exploits and jailbreaks are kept to small groups, individuals or are sold.

For example, I might know of an unrelated exploit I'm sitting on because I don't want it fixed and so far it hasn't been.

I think the climate has become one of those "don't correct your adversary when they make mistakes" types of things versus an older culture of release clout.

Re: Memory Integrity Enforcement

#105

Post by tptacek »

strcat wrote: post #100
saagarjha wrote: post #95

Earlier quoted context omitted.

None of this is wrong but none of this really has any impact on what Apple decided to do. In fact Apple very specifically chose not to go in this direction as they describe in their blog post.

The side channel fixes and new MTE instruction features are not specific to Apple. Apple's blog post has some significant misleading claims and omissions. It's marketing material, not a true technical post without massive bias. It's aimed at putting down the existing deployments of MTE, hyping up what they've done and even downplaying the factually widespread exploits of Apple devices which are proven to be happening…

I think you have to read "widespread malware attack" in Apple lit as a term of art; it's a part of the corporate identity dating back to the inception of the iPhone and (I think maybe) ties into some policy stuff that is very salient to them right now. I think SEAR is extremely aware of what real-world exploitation of iPhones looks like. You were never going to get their unfiltered take in a public blog post like this, though.

Re: Memory Integrity Enforcement

#106

Post by tptacek »

strcat wrote: post #98
tptacek wrote: post #22

Earlier quoted context omitted.

Even with Android MTE, one of the workarounds was probabilistic attacks on the small tag size, which imply multiple tries. One of the big distinctions here is uniform synchronous enforcement, so writes trap immediately and not on the next context switch.

It's typically used in synchronous or asymmetric mode on Android. The asymmetric mode preserves nearly the same performance as asymmetric while only having writes remain asynchronous. It's enforced once there's a read or system call. Synchronous is more important in the kernel due to how many holes there are for bypassing it, which is why GrapheneOS is using it as synchronous in the kernel and asymmetric in userspace…

You'd know better than I would; I'm a bystander on this whole area of development. I was really just responding to the notion that these countermeasures fall to attackers who get multiple bites at the apple --- those attackers are explicitly part of the threat model. I think I have realistic expectations about what this revision of MIE is going to do (raise costs, maybe over time wash out a lower tier of exploit developers on the platform).

Re: Memory Integrity Enforcement

#107

Post by strcat »

saagarjha wrote: post #92
philodeon wrote: post #73

> 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…

> It hasn’t been a meaningful attack deterrent because attackers keep finding PAC bypasses. Correction: it forces attackers to find PAC bypasses. They are not infinite.

Hijacking control flow like this is not a hard requirement of exploitation. Vulnerabilities in a specific software release are not infinite in general so that doesn't mean much.

Re: Memory Integrity Enforcement

#108

Post by commandersaki »

tptacek wrote: post #3

Both approaches revealed the same conclusion: Memory Integrity Enforcement vastly reduces the exploitation strategies available to attackers. Though memory corruption bugs are usually interchangeable, MIE cut off so many exploit steps at a fundamental level that it was not possible to restore the chains by swapping in new bugs. Even with substantial effort, we could not rebuild any of these chains to work around MIE.…

RIP Vigilant Labs

Okay a bit drastic, I don’t really know if this will affect them.

Re: Memory Integrity Enforcement

#109

Post by strcat »

tptacek wrote: post #105
strcat wrote: post #100

Earlier quoted context omitted.

The side channel fixes and new MTE instruction features are not specific to Apple. Apple's blog post has some significant misleading claims and omissions. It's marketing material, not a true technical post without massive bias. It's aimed at putting down the existing deployments of MTE, hyping up what they've done and even downplaying the factually widespread exploits of Apple devices which are proven to be happening…

I think you have to read "widespread malware attack" in Apple lit as a term of art; it's a part of the corporate identity dating back to the inception of the iPhone and (I think maybe) ties into some policy stuff that is very salient to them right now. I think SEAR is extremely aware of what real-world exploitation of iPhones looks like. You were never going to get their unfiltered take in a public blog post like thi…

> I think you have to read "widespread malware attack" in Apple lit as a term of art

There's widespread exploitation of Apple devices around the world by many governments, companies, etc. Apple and Google downplay it. The attacks are often not at all targeted but rather you visit a web page involving a specific political movement such as Catalan independence and get exploited via Safari or Chrome. That's not a highly targeted attack and is a typical example of how those exploits get deployed. The idea that they're solely used against specific individuals targeted by governments is simply not true. Apple and Google know that's the case but lead people to believe otherwise to promote their products as more safe than they are.

> I think SEAR is extremely aware of what real-world exploitation of iPhones looks like.

Doesn't seem that way based on their interactions with Citizen Lab and others.

Re: Memory Integrity Enforcement

#110

Post by commandersaki »

saurik wrote: post #48

> We believe memory safety protections need to be strictly synchronous, on by default, and working continuously. FWIW, I presume this is "from experience"--rather than, from first principles, which is how it comes off--as this is NOT how their early kernel memory protections worked ;P. In 2015, with iOS 9, Apple released Kernel Patch Protection (KPP), which would verify that the kernel hadn't been modified asynchrono…

Yeah it’s hard to get these things right the first time.
Post reply on HN