←back to thread

Memory Integrity Enforcement

(security.apple.com)
461 points circuit | 2 comments | 09 Sep 25 18:25 UTC | HN request time: 0.645s | 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 #
bri3d ◴[09 Sep 25 21:40 UTC] No.45189613[source]▶
I think I broadly agree with you. IMO tagging is practically much, much more valuable than capabilities systems modeled like CHERI.
replies(1): >>45189721 #
quotemstr ◴[09 Sep 25 21:49 UTC] No.45189721[source]▶
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. We use capabilities to build a hardware-software domain-transition mechanism and programming model suitable for safe communication between mutually distrusting software

and https://github.com/CTSRD-CHERI/cheripedia/wiki/Colocation-Tu...

> Processes are Unix' natural compartments, and a lot of existing software makes use of that model. The problem is, they are heavy-weight; communication and context switching overhead make using them for fine-grained compartmentalisation impractical. Cocalls, being fast (order of magnitude slower than a function call, order of magnitude faster than a cheapest syscall), aim to fix that problem.

This functionality revolves around two functions: cocall(2) for the caller (client) side, and coaccept(2) for the callee (service) side. Underneath they are implemented using CHERI magic in the form of CInvoke / LDPBR CPU instruction to switch protection domains without the need to enter the kernel, but from the API user point of view they mostly look like ordinary system calls and follow the same conventions, errno et al.

There's a decent chance that we get back whatever performance we pay for CHERI with interest as new systems architecture possibilities open up.

MTE helps us secure existing architectures. CHERI makes new architectures possible.

replies(1): >>45190296 #
saagarjha ◴[09 Sep 25 22:34 UTC] No.45190296[source]▶
Yes, but this breaks mirror mappings.
replies(1): >>45192097 #
1. jrtc27 ◴[10 Sep 25 01:49 UTC] No.45192097[source]▶
Can you elaborate on what you perceive as broken?
replies(1): >>45194424 #
2. saagarjha ◴[10 Sep 25 07:31 UTC] No.45194424[source]▶
mremap?