4 ms·

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 w

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

tptacek 1y ago
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.
- pizlonator 1y ago
  Yeah that’s really good. That makes the probability work against the attacker really well. But it’s not a guarantee
- strcat 1y ago
  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.
  - tptacek 1y ago
    You'd know better than I would; I'm a bystander on this whole area of development. I was really just responding to the notion that these countermeasures fall to attackers who get multiple bites at the apple --- those attackers are explicitly part of the threat model. I think I have realistic expectations about what this revision of MIE is going to do (raise costs, maybe over time wash out a lower tier of exploit developers on the platform).
    - strcat 1y ago
      I think they've likely done a great job implementing it and think it will significantly improve iPhone security. I dislike the over the top marketing resembling a technical blog post. It's as if they've deployed CHERI in production with near 0 overhead rather than an incremental improvement over what standard ARM Cortex cores shipped years ago which people have been using in production. Others are aware of where MTE needs improvement and are working on it for years. Cortex shipped MTE with a side channel issue which is better than not shipping it and it will get addressed. Apple has plenty of their own side channel vulnerabilities for their CPUs. Deterministic protections provided via MTE aren't negatively impacted by the side channel and also avoid depending on only 4 bits of entropy. The obvious way to use MTE is not the only way to use it. GrapheneOS began using MTE in production right after the Pixel 8 provided a production quality implementation, which was significantly later than it could have been made available since Pixels aren't early adopters of new Cortex cores. On those cores, asynchronous MTE is near free and asymmetric is comparable to something like -fstack-protector-strong. Synchronous is relatively expensive, so making that perform better than the early Cortex cores providing MTE seems to be where Apple made a significant improvement. Apple has higher end, larger cores than the current line of Cortex cores. Qualcomm's MTE implementation will be available soon and will be an interesting comparison. We expect Android to heavily adopt it and therefore it will be made faster out of necessity. The security advantage of synchronous over asymmetric for userspace is questionable. It's clearer within the kernel, where little CPU time is spent on an end user device. We use synchronous in the kernel and asymmetric in userspace. We haven't offered full synchronous as an option mainly because we don't have any example of it making a difference. System calls act as a synchronization point in addition to reads. io_uring isn't available beyond a few core processes, etc.
achierius 1y ago
The other 15/16 attempts would crash though, and a bug that unstable is not practically usable in production, both because it would be obvious to the user / send diagnostics upstream and because when you stack a few of those 15/16s together it's actually going to take quite a while to get lucky.
- pizlonator 1y ago
  I get that. That’s why I’m adding the caveat that this doesn’t protect you against attackers that are in a position to try multiple times
  - zarzavat 1y ago
    Detection is 14/15ths of the battle. Forcing attackers to produce a brand new exploit chain every few weeks massively increases attack cost which could make it uneconomical except for national security targets.
    - pizlonator 1y ago
      It will be really interesting to see how well that part of the story works out! What we're essentially saying is that evading detection is now 14/15 of the battle, from the attacker's perspective. Those people are very clever
- strcat 1y ago
  Typically 14/15 since a tag is normally reserved for metadata, free data, etc. Linux kernel reserves multiple for the internal kernel usage since it was introduced upstream as more of a hardware accelerated debugging feature even though it's very useful for hardening.
  - loeg 1y ago
    93%, 94%, it's not a huge difference.
  - achierius 1y ago
amelius 1y ago
It also won't help with supply-chain attacks. Executed by e.g. a state actor who is playing the long game.

tptacek 1y ago

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.

pizlonator 1y ago
Yeah that’s really good. That makes the probability work against the attacker really well. But it’s not a guarantee
strcat 1y ago
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.
- tptacek 1y ago
  You'd know better than I would; I'm a bystander on this whole area of development. I was really just responding to the notion that these countermeasures fall to attackers who get multiple bites at the apple --- those attackers are explicitly part of the threat model. I think I have realistic expectations about what this revision of MIE is going to do (raise costs, maybe over time wash out a lower tier of exploit developers on the platform).
  - strcat 1y ago
    I think they've likely done a great job implementing it and think it will significantly improve iPhone security. I dislike the over the top marketing resembling a technical blog post. It's as if they've deployed CHERI in production with near 0 overhead rather than an incremental improvement over what standard ARM Cortex cores shipped years ago which people have been using in production. Others are aware of where MTE needs improvement and are working on it for years. Cortex shipped MTE with a side channel issue which is better than not shipping it and it will get addressed. Apple has plenty of their own side channel vulnerabilities for their CPUs. Deterministic protections provided via MTE aren't negatively impacted by the side channel and also avoid depending on only 4 bits of entropy. The obvious way to use MTE is not the only way to use it. GrapheneOS began using MTE in production right after the Pixel 8 provided a production quality implementation, which was significantly later than it could have been made available since Pixels aren't early adopters of new Cortex cores. On those cores, asynchronous MTE is near free and asymmetric is comparable to something like -fstack-protector-strong. Synchronous is relatively expensive, so making that perform better than the early Cortex cores providing MTE seems to be where Apple made a significant improvement. Apple has higher end, larger cores than the current line of Cortex cores. Qualcomm's MTE implementation will be available soon and will be an interesting comparison. We expect Android to heavily adopt it and therefore it will be made faster out of necessity. The security advantage of synchronous over asymmetric for userspace is questionable. It's clearer within the kernel, where little CPU time is spent on an end user device. We use synchronous in the kernel and asymmetric in userspace. We haven't offered full synchronous as an option mainly because we don't have any example of it making a difference. System calls act as a synchronization point in addition to reads. io_uring isn't available beyond a few core processes, etc.

achierius 1y ago

The other 15/16 attempts would crash though, and a bug that unstable is not practically usable in production, both because it would be obvious to the user / send diagnostics upstream and because when you stack a few of those 15/16s together it's actually going to take quite a while to get lucky.

pizlonator 1y ago
I get that. That’s why I’m adding the caveat that this doesn’t protect you against attackers that are in a position to try multiple times
- zarzavat 1y ago
  Detection is 14/15ths of the battle. Forcing attackers to produce a brand new exploit chain every few weeks massively increases attack cost which could make it uneconomical except for national security targets.
  - pizlonator 1y ago
    It will be really interesting to see how well that part of the story works out! What we're essentially saying is that evading detection is now 14/15 of the battle, from the attacker's perspective. Those people are very clever
strcat 1y ago
Typically 14/15 since a tag is normally reserved for metadata, free data, etc. Linux kernel reserves multiple for the internal kernel usage since it was introduced upstream as more of a hardware accelerated debugging feature even though it's very useful for hardening.
- loeg 1y ago
  93%, 94%, it's not a huge difference.
- achierius 1y ago

amelius 1y ago

It also won't help with supply-chain attacks. Executed by e.g. a state actor who is playing the long game.