Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenBSD may soon gain further memory protections: immutable userland mappings

marc.info

Post reply on HN
Print view View original

21–30 of 72 posts

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

#21

Post by jart »

staticassertion wrote: post #14
jart wrote: post #7

Earlier quoted context omitted.

> Linux doesn't mandate any libc Neither does OpenBSD. You're misunderstanding how msyscall() works. It's like Highlander. There can be only one.

Ah, interesting, I'll have to dig into it more :) I've never used OpenBSD so I've just had to watch on the sidelines. Anywhere I can read more about this?

The msyscall() man page. The Cosmopolitan Libc source code. In the cosmoverse, we produce static executables that run on six operating systems. The only Libc we use is obviously our own. So when our executables get loaded on OpenBSD, we do the same thing OpenBSD Libc does, which is calling msyscall() so that only a privileged subset of the application is able to use SYSCALL. In our static binary world, that's basically any function that uses the `privileged` keyword. It makes things a little dicey if we want to dynamically link OpenBSD Libc since we have to pull out some aggressive hacks like Xed in that case. But overall it's fine.

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

#22

Post by jart »

eqvinox wrote: post #11
staticassertion wrote: post #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 directl…

> Because the stack frame for main contains a bunch of other stuff - environment variables, cli args, etc - […] > a) I bet some insane userland processes fuck with their stacks The new OpenBSD `mimmutable()` call, when applied on the stack, does absolutely nothing to prevent writing or reading the stack. It prevents changing the (virtual memory/pagetable) mapping itself, i.e. mapping in something else, removing the m…

Well it technically does if you make a new stack with mmap(MAP_STACK) (or simply round down the stack pointer by a page size) and remove the write access to the top of the original stack and mimmutable it.

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

#23

Post by chasil »

kyledrake wrote: post #2

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

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

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

#25

Post by chasil »

fsckboy wrote: post #18
bell-cot wrote: post #5

Earlier quoted context omitted.

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

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

#26

Post by eqvinox »

jart wrote: post #22
eqvinox wrote: post #11

Earlier quoted context omitted.

> Because the stack frame for main contains a bunch of other stuff - environment variables, cli args, etc - […] > a) I bet some insane userland processes fuck with their stacks The new OpenBSD `mimmutable()` call, when applied on the stack, does absolutely nothing to prevent writing or reading the stack. It prevents changing the (virtual memory/pagetable) mapping itself, i.e. mapping in something else, removing the m…

Well it technically does if you make a new stack with mmap(MAP_STACK) (or simply round down the stack pointer by a page size) and remove the write access to the top of the original stack and mimmutable it.

Problem is that those "magic variables" are defined by ABI to be directly above main()'s stack frame… if you're throwing that out, you may equally well leave the stack alone and put the magic stuff in some new place :)

…

Actually, now that I think about it, I guess you could try to put the boundary between main() and the magic bits right on a page boundary, and then change attrs on the magic bits?

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

#27

Post by jart »

eqvinox wrote: post #26
jart wrote: post #22

Earlier quoted context omitted.

Well it technically does if you make a new stack with mmap(MAP_STACK) (or simply round down the stack pointer by a page size) and remove the write access to the top of the original stack and mimmutable it.

Problem is that those "magic variables" are defined by ABI to be directly above main()'s stack frame… if you're throwing that out, you may equally well leave the stack alone and put the magic stuff in some new place :) … Actually, now that I think about it, I guess you could try to put the boundary between main() and the magic bits right on a page boundary, and then change attrs on the magic bits?

You mean _start()'s stack pointer. Libc can secure them and it's fine. It would probably break the ANSI C standard though if you can't modify argv and environ though. So Libc would need to copy them. But that limits the usefulness of the original tooling proposal unless the operating system has something like /proc/pid/maps that tells you the extent of the system provided stack. I don't think OpenBSD has that. Please prove me wrong since if it does, I'd love to know how.

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

#29

Post by na85 »

kyledrake wrote: post #2

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

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.

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

#30

Post by eqvinox »

jart wrote: post #27
eqvinox wrote: post #26

Earlier quoted context omitted.

Problem is that those "magic variables" are defined by ABI to be directly above main()'s stack frame… if you're throwing that out, you may equally well leave the stack alone and put the magic stuff in some new place :) … Actually, now that I think about it, I guess you could try to put the boundary between main() and the magic bits right on a page boundary, and then change attrs on the magic bits?

You mean _start()'s stack pointer. Libc can secure them and it's fine. It would probably break the ANSI C standard though if you can't modify argv and environ though. So Libc would need to copy them. But that limits the usefulness of the original tooling proposal unless the operating system has something like /proc/pid/maps that tells you the extent of the system provided stack. I don't think OpenBSD has that. Please…

> You mean _start()'s stack pointer.

Right, yeah.

> It would probably break the ANSI C standard though if you can't modify argv and environ though.

AFAIK it would also break setproctitle(), unless my memory is off that works by just writing over the argv space.

On the plus side, on Linux /proc//environ is a snapshot created at the time of execve() and kept by the kernel, nothing other than execve() can change it (don't quote me on this, I'm only 90% sure.)

Post reply on HN