←back to thread

Memory Integrity Enforcement

(security.apple.com)
461 points circuit | 5 comments | 09 Sep 25 18:25 UTC | HN request time: 0.435s | 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 #
1. bri3d ◴[09 Sep 25 21:07 UTC] No.45189145[source]▶
IMO it's the latter; CHERI requires a lot of heavy lifting at the compile-and-link layer that restricts application code behaviors, and an enormous change to the microarchitecture. On the other hand, heap-cookies / tag secrets can be delegated to the allocator at runtime in something like MIE / MTE, and existing component-level building blocks like the SPTM can provide some of the guarantees without needing a whole parallel memory architecture for capabilities like CHERI demands.
replies(3): >>45192088 #>>45194072 #>>45194123 #
2. jrtc27 ◴[10 Sep 25 01:48 UTC] No.45192088[source]▶
To reiterate what I've said elsewhere, CHERI does not need a whole parallel memory architecture, there is just one that gets a slight extension over a non-CHERI/MTE system to include tags. But that is the same story as MTE, which also needs to propagate the tags in the memory system (and in fact, more tags, since we just need one bit per 16 bytes, whereas MTE needs 4 bits per 16 bytes in the common scheme).
3. mschuster91 ◴[10 Sep 25 06:36 UTC] No.45194072[source]▶
> CHERI requires a lot of heavy lifting at the compile-and-link layer that restricts application code behaviors, and an enormous change to the microarchitecture.

Well, Apple already routinely forces developers to recompile their applications so if Apple wants to introduce something needing a compiler / toolchain update they can do that easily. And they also control the entire SoC from start to finish and unlike pretty much everyone else also hold an ARM Architecture License so they can go and change whatever they want in the hardware side as well.

4. checker659 ◴[10 Sep 25 06:43 UTC] No.45194123[source]▶
> compile-and-link layer

Not to mention the dynamic linker.

replies(1): >>45194569 #
5. jrtc27 ◴[10 Sep 25 07:50 UTC] No.45194569[source]▶
Yeah you need a compiler, linker and OS. That's true of any security technology. CHERI may be more significant in that regard because it's a bigger rethink than just stuffing some extra metadata into the existing types, but it's not at all intractable. We, a research group, maintain CheriBSD, a "full-fat" port of FreeBSD to CHERI (Morello and CHERI-RISC-V), so to a big tech organisation it's a small investment. The cost to tech companies is not making it work, it's often much more boring business factors.