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.

+1...but OpenBSD's webmaster might want to update that page, so it doesn't link to their 2020 Fundraising Campaign. (Their current Campaign - https://www.openbsdfoundation.org/campaign2022.html )

And "This security tech usually..." is a bit too modest. Just one example - OpenBSD is the origin of OpenSSH, which has been rather widely used for a decade or two now.

OpenBSD does great work, but for the record OpenSSH started as a fork of the free SSH program developed by Tatu Ylönen; later versions of Ylönen's SSH were proprietary software offered by SSH Communications Security.

https://en.wikipedia.org/wiki/OpenSSH

Realistically, OpenBSD completely reimplemented protocol 2 themselves.

Since nobody uses protocol 1 anymore, very little of the original code from Tatu Ylönen remains in operation with default settings.

ps I have had to use the SSH commercial release under VMS, and the compatibilities with OpenSSH are quite unpleasant.

i just read that page[1] earlier this week. this gives a great view on the amount of work performed by the openssh project after the fork of the last open source version.

[1] https://www.openssh.com/history.html

thanks for bringing this to our attention. fixed now: https://github.com/bob-beck/foundation-web/commit/d34479b48a...

This happens to already exist on macOS as VM_FLAGS_PERMANENT when setting up the mapping.

There honestly isn't that much "tech" to speak of here. We were literally talking about "immutable" mappings last week in Linux land: https://lore.kernel.org/all/b4f0dca5-1d15-67f7-4600-9a0a91e9...

That said, this would be great to see in OpenBSD (or any other OS).

Too bad they don't accept peer-to-peer electronic cash

> Bitcoin donation via BitPay: The OpenBSD Foundation can accept donations in BTC via BitPay

Peer-to-peer means there isn't a third party involved, and BTC stopped being electronic cash around 2014

Yeah, but ideally you should make a donation of lasting value.

Almost every donation and purchase I have made would have been far more lucrative to the recipient had they kept it in BTC. But yes, I understand this is salty HN.

That's what BitPay handles. The OpenBSD Foundation doesn't hold onto any Bitcoin, it's immediately converted into USD.

And thus the failure of BSD-style licensing is thrown into sharp relief:

Why are these projects that are used by many large and extraordinarily profitable tech enterprises dependent on community donations?

I recommend not donating, because to do so directly supports corporate parasitism.

Really? Their biggest donors are large and extraordinarily profitable tech enterprises. (Like Google, Microsoft, and Facebook)

And thus the success of BSD-style licensing is thrown into sharp relief. (Also the fact that you or I can go use it as much as we want for free and do whatever we want to it.)

The flip side of course is that improvements also come at the pace of volunteerism, and there are no boardroom meetings where a manager tells the BSD developers that they didn't type enough lines of code that week.

If a corp wants a feature improved or implemented if it doesn't exist, they will have to pay someone and then they have to decide whether they will contribute it. If they do not, then they have to maintain a fork themselves which requires ongoing resources.

At the end of the day, I don't think it really matters that much. The corps are providing a service not a software application. If they weren't using BSD, they'd be using something else.

There used to be complaint from OpenBSD that large corporate users of OpenSSH weren't donating anything, so I sent them $100.

Those days appear to be over.

https://www.theregister.com/2015/07/08/microsoft_donates_to_...

Better than nothing but it's far from what the title describes as "rains cash".

MS : $25k - $50k

Google , FB : $10k - $25k

For them, that's like saying "Hi". For the financial value the OpenBSD foundation is creating, that's a miniscule return.

It is a bit anemic, upon reflection.

Still, I haven't heard any recent complaint on fundraising goals.