←back to thread

Memory Integrity Enforcement

(security.apple.com)
458 points circuit | 2 comments | | HN request time: 0s | source
Show context
pizlonator ◴[] No.45188131[source]
This is really impressive.

It’s my understanding that this won’t protect you in the case where the attacker has a chance to try multiple times.

The approach would be something like: go out of bounds far enough to skip the directly adjacent object, or do a use after free with a lot of grooming, so that you get a a chance of getting a matching tag. The probability of getting a matching tag is 1/16.

But this post doesn’t provide enough details for me to be super confident about what I’m saying. Time will tell! If this is successful then the remaining exploit chains will have to rely on logic bugs, which would be super painful for the bad guys

replies(3): >>45188201 #>>45189018 #>>45198401 #
tptacek ◴[] No.45188201[source]
Even with Android MTE, one of the workarounds was probabilistic attacks on the small tag size, which imply multiple tries. One of the big distinctions here is uniform synchronous enforcement, so writes trap immediately and not on the next context switch.
replies(2): >>45188251 #>>45190489 #
strcat ◴[] No.45190489[source]
It's typically used in synchronous or asymmetric mode on Android. The asymmetric mode preserves nearly the same performance as asymmetric while only having writes remain asynchronous. It's enforced once there's a read or system call. Synchronous is more important in the kernel due to how many holes there are for bypassing it, which is why GrapheneOS is using it as synchronous in the kernel and asymmetric in userspace. io_uring is a major example of how there could be a major bypass of asymmetric mode, although Android doesn't allow it for more than a few core processes. Deploying asynchronous is still useful since it's a widely distributed bug finding tool with near zero cost. The main cost is that it finds so many bugs which need to be addressed which is a barrier for deploying it for third party apps.

The main weakness is that MTE is only 4 bits... and it's not even 1/16 but typically 1/15 chance of bypassing it since a tag is usually reserved for metadata, free data, etc. The Linux kernel's standard implementation for in-kernel usage unnecessarily reserves more than 1 to make debugging easier. MTE clears the way for a more serious security focused memory tagging implementation with far more bits and other features. It provides a clear path to providing very strong protection against the main classes of vulnerabilities used in exploits, especially remote/proximity ones. It's a great feature but it's more what it leads to that's very impressive than the current 4 bit MTE. Getting rid of some known side channels doesn't make it into a memory safety implementation.

replies(2): >>45190725 #>>45192908 #
vayup ◴[] No.45192908[source]
In theory, it is a 1/15 chance of successful attack. Which is a terribly low success rate of attack prevention.

In practice, it is 15/16 chance of detection of the exploit attempt. Which is an extraordinarily high rate of detection, which will lead to a fix by Apple.

Net net, huge win. But I agree they come across as overstating the prevention aspect.

replies(1): >>45194478 #
1. saagarjha ◴[] No.45194478[source]
1/16 is a miserable rate for commercial spyware; it would be very difficult to sell this kind of product for a remote 0- or 1-click attack.
replies(1): >>45197154 #
2. pizlonator ◴[] No.45197154[source]
It’s miserable today because you’d be competing with others selling deterministic attacks.

But what if the only thing available to purchase is 1/16 or 1/256? Then maybe it’s not so miserable