←back to thread

Memory Integrity Enforcement

(security.apple.com)
473 points circuit | 1 comments | 09 Sep 25 18:25 UTC | HN request time: 0.199s | source
Show context
tptacek ◴[09 Sep 25 18:51 UTC] No.45186809[source]▶
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. The few memory corruption effects that remained are unreliable and don’t give attackers sufficient momentum to successfully exploit these bugs.

This is great, and a bit of a buried lede. Some of the economics of mercenary spyware depend on chains with interchangeable parts, and countermeasures targeting that property directly are interesting.

replies(3): >>45188753 #>>45190761 #>>45191353 #
leoc ◴[09 Sep 25 20:45 UTC] No.45188753[source]▶
In terms of Apple Kremlinology, should this be seen a step towards full capability-based memory safety like CHERI ( https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_R... ) or more as Apple signaling that it thinks it can get by without something like CHERI?
replies(2): >>45189145 #>>45189370 #
pizlonator ◴[09 Sep 25 21:21 UTC] No.45189370[source]▶
MTE and CHERI are so different that it’s hard and maybe not even possible to do both at the same time (you might not have enough spare bits in a CHERI 128 bit ptr for the MTE tag)

They also imply a very different system architecture.

replies(3): >>45189425 #>>45189430 #>>45191990 #
quotemstr ◴[09 Sep 25 21:25 UTC] No.45189425[source]▶
> MTE and CHERI are so different that it’s hard and maybe not even possible to do both at the same time (you might not have enough spare bits in a CHERI 128 bit ptr for the MTE tag)

Why would you need MTE if you have CHERI?

replies(2): >>45189480 #>>45189490 #
pizlonator ◴[09 Sep 25 21:29 UTC] No.45189480[source]▶
Not saying you’d want both. Just answering why MTE isn’t a path to CHERI

But here’s a reason to do both: CHERI’s UAF story isn’t great. Adding MTE means you get a probabilistic story at least

replies(2): >>45189519 #>>45189544 #
bri3d ◴[09 Sep 25 21:34 UTC] No.45189544[source]▶
True! On the flip side, MTE sucks at intra-object corruption: if I get access to a heap object with pointers, MTE doesn't affect me, I can go ahead and write to that object because I own the tag.

Overall my _personal_ opinion is that CHERI is a huge win at a huge cost, while MTE is a huge win at a low cost. But, there are definitely vulnerability classes that each system excels at.

replies(1): >>45189587 #
pizlonator ◴[09 Sep 25 21:37 UTC] No.45189587[source]▶
I think the intra object issue might be niche enough to not matter.

And CHERI fixes it only optionally, if you accept having to change a lot more code

replies(2): >>45189613 #>>45192137 #
jrtc27 ◴[10 Sep 25 01:54 UTC] No.45192137[source]▶
Where studies suggest "a lot" is sub-0.1%. For example, https://www.capabilitieslimited.co.uk/_files/ugd/f4d681_e0f2... was a study into porting 6 million lines of C and C++ to run a KDE+X11 desktop stack on CHERI, and saw 0.026% LoC change, or ~1.5k LoC out of ~6 million LoC, all done in just 3 months by one person. That's even an overestimate, because it includes many changes to build systems just to be able to cross-compile the projects. It's not nothing, but it's the kind of thing where a single engineer can feasibly port large bodies of code. Yes, certain systems code will be worse (like JITs), but the vast majority of cases are not that, and even those are still feasible (e.g. we have people working with Chromium and V8).
replies(1): >>45197116 #
1. pizlonator ◴[10 Sep 25 13:11 UTC] No.45197116[source]▶
Does that study include enabling intra object overflow protection, or not?

When I say that this optional feature would force you to change a lot more code I’m comparing CHERI without intra object overflow protection to CHERI with intra object object overflow protection.

Finally, 6 million lines of code is not that impressive. Real OSes are measured in billions