The people cursing about the mitigations do not have a day job writing attacks against the same targets over and over again; conversely, those that do, do not bitch about mitigations that much. :-)
Conversation
The reality is: Mitigations can be really annoying to bypass the first few times, and mildly annoying even after N times, while being still largely ineffective at stopping any attack.
1
2
7
Totally depends on the bug you have. The most constrained you are for bugs, the more potential for impact they have. L
1
1
Yes, I have seen a bug be made unexploitable by a mitigation. Is it the norm? Heck no. Do professional vulndevs look for bugs that fit a pattern that makes exploitation easy? Yes. Do we have evidence that mitigations regularly push bugs into nonexploitable territory? I think not.
3
1
6
But I agree on one thing: If you are severely bug- and interaction-restrained, mitigations *may* make a difference. But mostly they waste some of the attackers time, and a commensurate amount of defender time, so everybody happily keeps busy to no measurable effect :)
3
1
2
Also - not all mitigations, not all the time. CFI can provide benefits if not in a modern browser and in a reasonably sandboxes single-threaded server.
1
1
Memory tagging and SPARC ADI are hugely promising technologies, much more so than any hardware CFI support etc.
2
1
Memory tagging is a very loose approximation of dynamic memory safety checking though. Can have some nice deterministic guarantees like easily guaranteeing every small / linear heap overflow is caught but for arbitrary read/write it's a very low entropy probabilistic mitigation.
1
1
I think one of the major benefits will be that it's essentially like having ASan deployed in production at a very low cost. It will be really good for eliminating large swaths of bugs by detecting them a high percentage of the time in production. Decent chance to bypass though.
1
SPARC ADI and ARMv8.5 MTE have 4-bit tags. It's really not a lot of entropy for mitigating arbitrary read/write. Can reserve a tag never used for active heap allocations to mark freed data or maybe other things like a shadow stack as another mitigation. Not a lot of tags though.
1
1
I'd really like to see proper efficient hardware support for integer overflow checking by propagating poison values internally and then trapping when attempting to use a value. Main barrier to automatic checking even in many higher level languages is the high performance cost.
I don't like that they spend so much time adding weak mitigations like ARMv8.3 pointer authentication instead of adding building blocks for actual safety with high performance. Accumulated cost of all these weak mitigations adds up and they might as well just do the real thing.
Why is poison and deferred checking needed? Just trap at the time of overflow. Inserting 100%-predicted "jo" insns all over the place shouldn't even hurt performance though; no need for new hardware.
1
It does hurt performance substantially though. Even instructions that trap on overflow strictly would likely substantially hurt performance even though it's the same number of instructions. It makes much worse usage of the hardware and the effects hurt compiler optimization too.
1
Show replies