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

131–140 of 259 posts

Re: Memory Integrity Enforcement

#131

Post by strcat »

MBCook wrote: post #121
ysnp wrote: post #53

Earlier quoted context omitted.

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…

Personally I had no idea anyone had shipped this. I knew that MTE existed, though I don’t think I knew about EMTE. Nice to hear it’s already in use in some forms. And of course it seems pretty obvious that if this is in the new iPhones it’s going to be in the M5 or M6 chips.

ARM shipped it as a standard feature of Cortex cores significantly after it was added as an ISA extension. MediaTek and Exynos provide it and Snapdragon is approaching shipping an implementation.

Google set it up for usage on Pixels, and then later Samsung and others did too. Pixel 8 was the first device where it was actually usable and production quality. GrapheneOS began using it in production nearly immediately after it launched on the Pixel 8.

Re: Memory Integrity Enforcement

#132

Post by tptacek »

ignoramous wrote: post #128
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.…

> This is great ... That's Apple and here is Google (who have been at memory safety since the early Chrome/Android days): Google folks were responsible for pushing on Hardware MTE ... It originally came from the folks who also did work on ASAN, syzkaller, etc ... with the help and support of folks in Android ... ARM/etc as well. I was the director for the teams that created/pushed on it ... So I'm very familiar with…

This is a Daniel Berlin post explaining why Google didn't originally enable MTE full-time on Android. It explicitly acknowledges that keeping MTE enforcement enabled for everyone would block vulnerabilities.

Re: Memory Integrity Enforcement

#133

Post by aloha2436 »

bergfest wrote: post #52

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.

> MIE will make sure we can never take back our freedom.

Is the implication here that making phones more secure is... bad? Because it makes jailbreaks harder to develop?

Re: Memory Integrity Enforcement

#134

Post by elcritch »

bergfest wrote: post #52

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.

What is WEI?

Re: Memory Integrity Enforcement

#135

Post by ls612 »

elcritch wrote: post #134
bergfest wrote: post #52

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.

What is WEI?

Google proposed it as DRM for web pages in 2023. After much outcry it was unceremoniously withdrawn.

Re: Memory Integrity Enforcement

#136

Post by commandersaki »

ghostpepper wrote: post #113
strcat wrote: post #103

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. 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"?

I don't think this constitutes as widespread at least in impact, but there's been times where malicious apps have made it on the App store and used to steal cryptocurrency.

Re: Memory Integrity Enforcement

#137

Post by [deleted] »

achierius wrote: post #130
MBCook wrote: post #120

Earlier quoted context omitted.

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

> It sounds like the kernel’s allocations may only use one tag What about the blogpost suggested this? " ... always-on memory safety protection for our key attack surfaces including the kernel ..." " ... always-on memory-safety protection covering key attack surfaces — including the kernel and over 70 userland processes — built on the Enhanced Memory Tagging Extension (EMTE) and supported by secure typed allocators a…

[deleted]

Re: Memory Integrity Enforcement

#138

Post by duskwuff »

aloha2436 wrote: post #133
bergfest wrote: post #52

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.

> MIE will make sure we can never take back our freedom. Is the implication here that making phones more secure is... bad? Because it makes jailbreaks harder to develop?

I think it is. I've seen similar rhetoric from a few people in this thread, and it's extraordinarily silly. Apple is not developing this technology to make it harder to install torrent apps*; there's real problems they're trying to solve.

*: or whatever else people use jailbreaks for these days

Re: Memory Integrity Enforcement

#139

Post by commandersaki »

strcat wrote: post #127
tptacek wrote: post #106

Earlier quoted context omitted.

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

I think they've likely done a great job implementing it and think it will significantly improve iPhone security. I dislike the over the top marketing resembling a technical blog post. It's as if they've deployed CHERI in production with near 0 overhead rather than an incremental improvement over what standard ARM Cortex cores shipped years ago which people have been using in production. Others are aware of where MTE…

I think they've likely done a great job implementing it and think it will significantly improve iPhone security. I dislike the over the top marketing resembling a technical blog post. It's as if they've deployed CHERI in production with near 0 overhead rather than an incremental improvement over what standard ARM Cortex cores shipped years ago which people have been using in production.

I just want to address this part. Why shouldn't Apple advertise or market its achievements here? If they're effectively mitigating and/or frustrating real world attacks and seems to eliminate a class of security bugs, why shouldn't they boast about it; it shows that security R&D is in the forefront of the products they build which is an effective strategy for selling more product to the security conscious consumer.

Not a shill, but a shareholder, and I invest in Apple because they're at the forefront of a lot of tech.

Re: Memory Integrity Enforcement

#140

Post by strcat »

tptacek wrote: post #117
strcat wrote: post #109

Earlier quoted context omitted.

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

We have regular contact with many people at Google in that space and nearly no contact with anyone at Apple as a whole. Sometimes people we know go to work at Apple and become nearly radio silent about anything technical.

It's often external parties finding exploits being used in the wild and reporting it to Apple and Google. Citizen Lab, Amnesty International, etc.

We regularly receive info from people working at or previously working at companies developing exploits and especially from people at organization using those exploits. A lot of our perspective on it is based on having documentation on capabilities, technical documents, etc. from this over a long period of time. Sometimes we even get access to outdated exploit code. It's major releases bringing lots of code churn, replaced components and new mitigations which seem to regularly break exploits rather than security patches. A lot of the vulnerabilities keep working for years and then suddenly the component they exploited was rewritten so it doesn't work anymore. There's not as much pressure on them to develop new exploits regularly as people seem to think.

Post reply on HN