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

111–120 of 259 posts

Re: Memory Integrity Enforcement

#111

Post by bigiain »

strcat wrote: post #83
randyrand wrote: post #68

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

> tools like Cellebrite Premium which are used against many people crossing borders

I wonder when the first person will be turned away from a US border for having an iPhone Air that the CBPs phone extraction tool doesn't work on?

Re: Memory Integrity Enforcement

#112

Post by MBCook »

bri3d wrote: post #75
als0 wrote: post #70

Earlier quoted context omitted.

Second bus?

CHERI fundamentally relies on capabilities living in memory that is architecturally separate from program memory. You could do so using a bus firewall, but then you're at the same place as MIE with the SPTM.

So something like having built in RAM for the pagetables that aren’t part of the normal pool? That way no matter what kind of attack you come up with user space cannot pass a pointer to it?

Re: Memory Integrity Enforcement

#113

Post by ghostpepper »

strcat wrote: post #103
saagarjha wrote: post #90

Earlier quoted context omitted.

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

Can you be more specific on what you consider "widespread" vs "rare"?

Re: Memory Integrity Enforcement

#114

Post by MBCook »

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…

> FWIW, I presume this is "from experience"--rather than, from first principles, which is how it comes off

I interpreted that as what they came up with when first looking at/starting to implement MTE, not their plan since $longTimeAgo.

Apple has certainly gotten better about security, and I suspect things like what you listed are a big part of why. They were clearly forced to learn a lot by jailbreakers.

Re: Memory Integrity Enforcement

#115

Post by ghostpepper »

sfink wrote: post #88
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…

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…

Making attackers work harder is still a worthwhile goal. No security is perfect.

Re: Memory Integrity Enforcement

#116

Post by MBCook »

saagarjha wrote: post #91
randyrand wrote: post #68

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

It's mainly there as a swipe at Android. I don't think it really relates to the rest of the article (and, with no insight but with my conspiracy theory hat on, was included to peddle the merits of their App Store model).

Even without going conspiracy theory it fits very well as a simple marketing message. “We try hard at security and we do a good job of it. Here’s our newest tool.”

Personally I didn’t read it as a swipe against Android. If it was I don’t personally know what attack(s) it’s referring to outside of the possibility of malware installed by the vendor.

But if it’s installed by the vendor, they can really do anything can’t they. That’s not really a security breach. Just trust.

Re: Memory Integrity Enforcement

#117

Post by tptacek »

strcat wrote: post #109
tptacek wrote: post #105

Earlier quoted context omitted.

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…

I understood the point you were making previously and was not pushing back on it. I think you're wrong about SEAR's situational awareness, though. Do you know many people there? I'd be surprised if not. Platform security is kind of an incestuous scene.

Re: Memory Integrity Enforcement

#118

Post by slashtab »

saagarjha wrote: post #47
ysnp wrote: 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.

So Apple did research and Daniel just “turned it on”?! I am not talking about Hardware part even then you're biased and dismissive of other's effort.

Re: Memory Integrity Enforcement

#119

Post by tptacek »

commandersaki wrote: post #108
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.

I think they're going to print money hats, but we'll see. Remember: there isn't a realistic ceiling on what NATO-friendly intelligence and law enforcement agencies will pay for this technology; it competes with human intelligence, which is nosebleed expensive.

Re: Memory Integrity Enforcement

#120

Post by MBCook »

sfink wrote: post #94
pandalicious wrote: post #80

> The presence of EMTE leaves Spectre V1 as one of the last avenues available to attackers to help guide their attacks, so we designed a completely novel mitigation that limits the effective reach of Spectre V1 leaks — at virtually zero CPU cost — and forces attackers to contend with type segregation. This mitigation makes it impractical for attackers to use Spectre V1, as they would typically need 25 or more V1 sequ…

Nope. I don't know why just checking the tags during speculation wouldn't stop Spectre V1, at least for cross-type accesses? I mean, it's not that simple because your program won't crash if speculation has mismatched tags. Which means you can try as many times as you want until you get lucky. But that's certainly not a "completely novel mitigation", so I'm sure I'm missing something obvious. Perhaps the real problem…

You’re on the right track, I think. The mastodon link posted in a sibling comment within a minute of yours provides more details:

It sounds like the kernel’s allocations may only use one tag(?). So if you get in there, jackpot right? No tags to deal with.

So they’re using special compiler flags to limit all offsets to less than 4 GB. Then they placed different parts of the kernel far apart in address space with a 4 GB unmapped zone.

So if you can put your own pointer somewhere that’s exploitable in allocated kernel memory, there is no way for it to point to any other “part” of kernel memory. Only within that one “area”.

Presumably this would mean that exploiting a problem in the graphics drivers would not make it possible to provide a pointer pointing to the Secure Enclave interface code. Or something like that.

I’m not 100% on if I’m understanding it correctly.

Post reply on HN