Conversation

I am not sure that many people with deep offensive experience would agree that fine-grained KASLR is a good solution here (but I've had this discussion many times in the past and am frankly tired that it keeps coming back).

Quote Tweet

Kees Cook

@kees_cook

Nov 22, 2021

2/n: single-leak KASLR exposure reinforcing the need for Function-Granular KASLR. While KASLR adds an additional hurdle, a single exposure will fully bypass it. Gaining FGKASLR would strongly diminish the value of a single exposure. github.com/KSPP/linux/iss

Show this thread

Replying to

Yup, rational people disagree about this. I'm not suggesting it'll always be a win, but it is likely better than only KASLR. A little more of my thinking here:

Quote Tweet

Kees Cook

@kees_cook

Nov 23, 2021

Replying to @daveaitel

Different people measure the trade-offs differently. I've always held making mitigations _available_ is the key to progressive improvement. The devel, discussions, and use of mitigations leads to evolution of the space, whether it be the improvement or elimination of options.

Replying to

Can you find and name even a handful of bugs that were exploited for local privesc that you are sure cannot be reworked to be exploitable in the presence of FGASLR? I am happy to change my mind on FGASLR if someone does steps 1 and 2 described here: addxorrol.blogspot.com/2020/03/before

Replying to

As you suggested earlier, many could be reworked to be data-only attacks.

@tehjh

even provided a walkthrough for UaF: googleprojectzero.blogspot.com/2021/10/how-si But without a reason to abandon "easy" exec control flow hijacking, there's no incentive to switch.

Replying to

and

CFI + ShadowCallStack are already doing a good job against very constrained memory corruption bugs. I don't see what any mitigations short of detecting/preventing memory corruption can realistically do against more dangerous primitives. You can simply change process privileges.

Replying to

Taking over kernel control flow is entirely optional and not required for anything attackers actually want to accomplish. If they want to do that, then they have so much available to them including the page tables and immense amount of other things.

Replying to

ARMv8.5 memory tagging approach only has 4-bit tags. If you have 128-bit tags via fat pointers, you could have strong memory safety. At a certain point, it would be a whole lot less work and actually more performant to just implement memory safety instead of weak mitigations.

Replying to

MTE sounds a lot more useful for sanitizing (HWASAN) than as a mitigation. I’m a lot more excited about ARM8.3 PAC for that.

Replying to

MTE is quite powerful despite 4-bit tag limitation. It can be used to provide deterministic guarantees. It has explicit support for reserving tags. OS reserving a single tag for internal use allows it to protect all kinds of metadata, make 16 byte granularity 'guard pages', etc.

Replying to

ShadowCallStack, inline malloc metadata, freed allocations, etc. can be protected with a single reserved tag. Making sure adjacent allocations have different tags or having protected metadata between them wipes out small / linear overflows. Can do a lot more than random tags.

8:57 PM · Nov 24, 2021Twitter Web App

Replying to

I think it's far more compelling than PAC even if you disregard the ability to use random tags and use entirely deterministic ones. PAC is yet another attempt at targeting exploit techniques. Only protects specific pointers rather than memory in general. IMO, it's underwhelming.

Replying to

PAC is at odds with using the address space for exploit mitigations. It's directly opposed to approaches like splitting up the address space and avoiding reuse which is a *deterministic* UAF mitigation. It isn't just taking away bits from ASLR but also more interesting things.

Show replies