Live data from Hacker News

OpenBSD may soon gain further memory protections: immutable userland mappings

marc.info

1–10 of 72 posts

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

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

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

#6
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 directly from kernel structures, which is fine, but most people aren't doing that.

And then of course there's other cool stuff like being able to 'lock' system calls to the system provided libc, which openbsd can do since they already only support their provided libc.

Unfortunately none of this is likely to get to Linux at any point because:

a) I bet some insane userland processes fuck with their stacks

b) Linux doesn't mandate any libc

edit: Seems like there's some "what is this" being asked. Here's my loose understand!

For starters, libc is the interface to the kernel. Very few programs make syscalls directly (except go programs i guess? lol) on Linux, but on openbsd it's just flat out not allowed. OpenBSD doesn't have the "GNU/Linux" dichotomy - it's all one package deal. As such, they get to mandate how userland calls into the kernel.

Of course, you don't have to listen to openbsd today, because you can just... make those system calls directly. Easy. And this is relevant for security because attackers will do something called ROP, which effectively "reuses" bits of your already-executable code to issue system calls (you can google "return to libc" or "ret2libc").

So, first thing's first, have the kernel actually ensure that the sycall is issued from the memory that libc is mapped into. Cool, solved sort of.

But what if the attacker overwrites that libc? Now you've verified that the call is coming from libc but you don't have integrity.

With immutability the kernel will now enforce that system calls come from libc and that the code can't be overwritten.

Of course, this can extend beyond libc, but I'm assuming that's the main point. This would presumably be a general system call that programs can use themselves to do all sorts of fun things.

edit: Can't respond to replies, HN rate limited me :) sorry. Sounds like I need to read up a bit more, this doesn't address the use case I'd had in mind sadly, but still very cool nonetheless.

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

#7

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…

> Linux doesn't mandate any libc

Neither does OpenBSD. You're misunderstanding how msyscall() works. It's like Highlander. There can be only one.

Post reply on HN