Re:OpenBSD may soon gain further memory protections: immutab...
by saagarjha on Friday September 02, 2022 @04:54PM
(#32695607)
This is because the ROP gadget hardening OpenBSD does is generally considered to be mostly useless by other kernels, which are moving to hardware-enforced control flow integrity instead.
[ Parent
| on HN ]
Re:OpenBSD may soon gain further memory protections: immutab...
by chasil on Friday September 02, 2022 @05:32PM
(#32695953)
I prefer to do all my financial transactions from Chromium on OpenBSD, on a machine where I have run me_cleaner.
Am I happy to have ROP safeguards? You bet!
Re:OpenBSD may soon gain further memory protections: immutab...
by beachhead on Friday September 02, 2022 @05:55PM
(#32696162)
Is the ROP gadget hardening OpenBSD does mostly useless tho? Can you elaborate?
Re:OpenBSD may soon gain further memory protections: immutab...
by saagarjha on Friday September 02, 2022 @09:41PM
(#32697736)
The issue is largely that the OpenBSD authors don’t really seem to understand how actual ROP chains work, so their mitigations are tailored towards things that don’t actually match reality. For example, trapsled is meant to protect against sloppy/partial overwrites writes that take advantage of nops to slide to where attackers actually want to go. The problem is that using nop slides in a ROP chain is Not A Thing. People don’t do it, it’s literally a thing they thought sounds like a reasonable attack but it actually protects against nothing in the real world. Similarly, gadget removal is cool and all but their understanding of how well it works is very flawed. Their analysis relies on really dumb, off-the-shelf gadget finders for one. But more critically, they claim something like 90% gadget reduction as if this actually protects against a significant majority of attacks. It does not. Exploit developers are usually not constrained by the gadgets they have available to them. If there are a thousand gadgets and you reduce it to hundred, yes you probably killed a lot of good gadgets…but in the remaining ones there’s usually enough to still perform whatever you want, maybe with a little more difficulty.
These mitigations don’t really harm anything so they’re not bad, per se, but they’re definitely not particularly impactful when to comes to security so nobody else really thinks it’s worth implementing them. There’s a lot of stuff like this in OpenBSD, but to be fair a lot of other projects are also bad at making mitigations that aren’t very useful. Reading writeups on CTFtime or, heaven forbid, imagining what exploits would look like is sadly too common.
Re:OpenBSD may soon gain further memory protections: immutab...
by beachhead on Saturday September 03, 2022 @02:30PM
(#32704678)
Thank you for taking the time to reply and explain things to me. I appreciate it. I've nothing else to add because I just wanted to know more.
Re:OpenBSD may soon gain further memory protections: immutab...
by saagarjha on Saturday September 03, 2022 @06:10PM
(#32706622)
That’s fine :)
Re:OpenBSD may soon gain further memory protections: immutab...
by Veliladon on Friday September 02, 2022 @06:37PM
(#32696480)
ARM for instance has pointer authentication built into its hardware since version 8.3 of the ISA. While it's not the same implementation as OpenBSD, it has the same practical effect of making sure the return address is valid.
Re:OpenBSD may soon gain further memory protections: immutab...
by beachhead on Friday September 02, 2022 @06:53PM
(#32696634)
Right. So, how does that render OpenBSD's useless? Maybe I'm not being clear about what I'm asking here. I'm not comparing software vs hardware CFI. OpenBSD doesn't have support for PAC or CET (That I know of) but that doesn't mean they won't in the future. Should there be no software CFI then? Perhaps they would eventually complement each other?