Comment by chasil | Hacker News Reader

Comment by chasil | Hacker News Reader

Parent Full thread

The ROP-gadget stuff hasn't migrated to any other kernels that I have seen.

As I understand it, previous ROP-gadget hardening included compiler modifications on system/function call return, trap sleds, and some other stuff that I don't remember. This is on top of the kernel and library relink at every boot (to really make ASLR more potent).

These modifications include a verification that the jump is in the stack, and not at the tail of some function (and the other thing eludes my understanding).

These are some OpenBSD references on ROP hardening:

https://undeadly.org/cgi?action=article;sid=20170622065629

https://www.openbsd.org/papers/rop.pdf

https://www.openbsd.org/papers/asiabsdcon2019-rop-paper.pdf

I think that the most notorious exploit of "Return-Oriented Programming" (ROP-gadget) flaws was Solarwinds; I understand that a ROP exploit sealed their fate. Maybe Windows is doing some of this in their kernel.

"At this point, we noticed that Serv-U.dll and RhinoNET.dll both have ASLR support disabled, making them prime locations for ROP gadgets..."

https://www.microsoft.com/security/blog/2021/09/02/a-deep-di...

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.

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!

Is the ROP gadget hardening OpenBSD does mostly useless tho? Can you elaborate?

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.

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.

That’s fine :)

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.

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?

Hahaha EVERY time.

Reply on news.ycombinator.com