←back to thread

Memory Integrity Enforcement

(security.apple.com)
458 points circuit | 2 comments | 09 Sep 25 18:25 UTC | HN request time: 0.037s | 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 #
bri3d ◴[09 Sep 25 21:30 UTC] No.45189490[source]▶
Why would you need CHERI if you have working mitigations that don't demand a second bus?

I think it's two halves of the same coin and Apple chose the second half of the coin.

The two systems are largely orthogonal; I think if Apple chose to go from one to the other it will be a generational change rather than an incremental one. The advantage of MTE/MIE is you can do it incrementally by just changing the high bits the allocator supplies; CHERI requires a fundamental paradigm shift. Apple love paradigm shifts but there's no indication they're going to do one here; if they do, it will be a separate effort.

replies(2): >>45189560 #>>45189567 #
pizlonator ◴[09 Sep 25 21:36 UTC] No.45189567[source]▶
CHERI is deterministic.

That’s strictly better, in theory.

(Not sure it’s practically better. You could make an argument that it’s not.)

replies(2): >>45189645 #>>45193366 #
1. VogonPoetry ◴[10 Sep 25 04:40 UTC] No.45193366[source]▶
This is on the verge of pedantry - CHERI determinism isn't strictly true, garbage collecting abandoned descriptors is currently done asynchronously. Malicious code could attempt to reuse an abandoned descriptor before it is "disappeared". I think it might be possible to construct a synthetic situation where two threads operating with perhaps different privilege in the same address space (something CHERI can support!) have an IPC channel might be affected by the timing.

There is a section in the technical reports that talks about garbage collection.

I don't think CHERI is currently being used with different privileged threads in the same address space.

replies(1): >>45195078 #
2. Findecanor ◴[10 Sep 25 08:58 UTC] No.45195078[source]▶
I suspect that the parent poster was referring to MTE's memory protection being probabilistic. There are only 16 tag values for an attacker to guess. You can combine MTE and PAC, but PAC is also only probabilistic.

With CHERI, there is nothing to guess. You either have a capability or you don't.