Live data from Hacker News

OpenBSD may soon gain further memory protections: immutable userland mappings

marc.info

51–60 of 72 posts

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#51

Earlier quoted context omitted.

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.

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

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: immutable userland mappings

#52

I was just discussing this sort of thing with some colleagues. Because the stack frame for main contains a bunch of other stuff - environment variables, cli args, etc - it makes it unreliable to try to instrument Linux systems and collect that information. A process can change its name, args, env, at any time. That sort of information is really helpful for forensics. Currently your only option is to pull data directl…

> Very few programs make syscalls directly (except go programs i guess? lol) on Linux

You’re forgetting statically compiled binaries, which are very important for ease of deployment and distro-agnostic execution.

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#53

Earlier quoted context omitted.

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

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?

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#54
post #28

Earlier quoted context omitted.

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

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

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#55

Earlier quoted context omitted.

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.

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.

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#56
post #9

Now all we need is for PROT_EXEC to not imply PROT_READ like Android.

It is not think that improves security as an attacker does not need to read the executable code (remotely) to find the gadget or attack. More precisely, it is unreliable to rely on the confidentiality of such static information to achieve security.

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#57
post #54

Earlier quoted context omitted.

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

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

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

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#58
post #54

Earlier quoted context omitted.

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

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.

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#59
post #5

This security tech usually ends up in other platforms too, strongly recommend donating to their work: https://www.openbsdfoundation.org/donations.html

+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.

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

Re: OpenBSD may soon gain further memory protections: immutable userland mappings

#60
post #48
post #29

Earlier quoted context omitted.

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.

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.

Post reply on HN