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).
Kees Cook @kees_cook
22 Nov 2021
Replying to @kees_cook
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/issues…
5
7
2
52
You’re unable to view this Post because this account owner limits who can view their Posts.
Don't get me started on this. There's a cultish following of people with limited offensive experience that argue that it should be done against local kernel exploits, neglecting the fact that you can pretty much always rework a local to be data-only.
1
7
This Post was deleted by the Post author.
Is "narrowing the design space for the attacker" an actual win, though, or a mechanism to feel good about "having done something"? Pretty much anything "narrows the design space", I think we should hold ourselves to a higher standard of evidence than that.
2
1
3
I think my broader point is: Without super clearly articulated and documented goals & claims, mitigations can be put into systems that nobody will ever dare remove even decades after they have shown themselves to be failures.
1
4
I would be in favour of FGKASLR if we had a document that makes quantifiable & verifiable claims about what it intends to achieve (in terms of bugs or bugclasses rendered unexploitable), some evidence that these claims hold, and s commitment to remove FGKASLR if ...
1
2
...the claims are not achieved. In some sense, FGKASLR for me is the poster child of our common refusal to apply anything resembling a scientific method to defensive measures - instead we are arguing unquantifiable "raises the bar", "narrows the design space" etc.
1
4
We should hold ourselves to a higher standard than that. Shipping a useless mitigation that will live forever and add complexity and cost to the entire world is strictly worse than not shipping it.
1
7
Replying to @halvarflake @kees_cook @4Dgifts
heh, when was the last time any linux upstream security measure was held to that bar? it's no wonder it works this way since noone there can judge them on security merits, only general code design/complexity/etc ones. fortunately "depends on BROKEN_SECURITY" fixes the worst :).

Nov 25, 2021 · 10:21 AM UTC
2