Live data from Hacker News

OpenBSD may soon gain further memory protections: immutable userland mappings

marc.info

61–70 of 72 posts

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

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

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

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

#62
post #25
post #18

Earlier quoted context omitted.

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.

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

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

#63
post #30

Earlier quoted context omitted.

> 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 (do…

> 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.) prctl(PR_SET_MM_ENV_{START,END}) will change the contents of /proc/ /environ. From what it looks like in Linux's source code, twiddling the bits at the base of the stack will also cause the procfs file to change--it se…

Now I'm sad :(

… but Thanks for removing a misconception of mine!

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

#64
post #30

Earlier quoted context omitted.

> 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 (do…

No setproctitle on Linux. As far as I know you have to overwrite the argv space (and hopefully not also the environment space).

Looking at the sibling post to yours, I'm assuming the "better" approach these days is to allocate a new buffer distinct from argv space and use PR_SET_MM_ARG_{START,END} to point the kernel there.

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

#65
post #60
post #48

Earlier quoted context omitted.

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.

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

#66

Earlier quoted context omitted.

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

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.

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

#67
post #23

Earlier quoted context omitted.

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…

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.

Hahaha EVERY time.

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

#68
post #17

What exploit technique is this mitigating?

That’s always a good question to ask :) Seems like the claim is that it prevents exploits where you’d map libc executable and then spray code there. IMO if you have the ability to do this you usually have lost already but ¯\_(ツ)_/¯

Every time!

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

#69

Earlier quoted context omitted.

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

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 :)

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

#70
post #46

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…

> a) I bet some insane userland processes fuck with their stacks What do you mean by "insane" here? In standard C you get char** argv, and the arguments live on the stack. I believe you are allowed to modify those cli arguments through the pointers, it is not undefined behavior.

I never called it undefined behavior. But you shouldn't modify that stack space directly, you should either use setenv via libc or you should use prctl.
Post reply on HN