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

Beyond the strictly defensive characteristics of mitigations, there is the impact on research. E.g. KASLR wasn't the _reason_ Meltdown was found, but it was a contributor. Finding a way to use cache timing to bypass KASLR was a driver for further novel security research.

Replying to

and

If all new published attacks end up directly manipulating PTEs, how will the industry respond? There still isn't wide rollout of hardware memory tagging, and there has been years of research showing how valuable that would be.

Replying to

and

HWAsan is a partially hardware accelerated implementation based on the baseline ARMv8 Top Byte Ignore (TBI) feature. It would be entirely possible to implement it fully in software. Could also use high entropy random tags instead of tiny ones in the upper bits of pointers.

7:47 AM · Nov 24, 2021Twitter Web App

Replying to

ARMv8.5 has 4-bit tags with 16 byte granularity (3.125% overhead for tagged memory). If pointers were 16 bytes, it would provide 64 extra bits for the tags in addition to the 24 or so bits you can take from the upper bits of the address. Would also need larger granularity.

Replying to

88 bit tags would be 15.625% memory overhead for tagged memory with 64 byte granularity (16 byte pointers using the upper 24 bits of address + 8 bytes). Even if it still had 20% overhead with hardware support it'd be a small price to pay to bolt memory safety onto legacy C code.

Show replies