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

41–50 of 72 posts

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

#41

Post by 7vUYjPAG2fnx7fd »

eqvinox wrote: post #30
jart wrote: post #27

Earlier quoted context omitted.

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

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

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

#42

Post by jcranmer »

eqvinox wrote: post #30
jart wrote: post #27

Earlier quoted context omitted.

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 (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 seems to read directly from the process's memory. Ditto for /cmdline and /auxv, it seems.

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

#43

Post by saagarjha »

pram wrote: post #10
alberth wrote: post #3

This is beyond my knowledge but is this akin to macOS binary/memory protection for the base system OS?

Seems like the second blurb is similar to the Page Protection Layer+Pointer Authentication Codes in XNU.

Not really, PPL protects page tables and PAC provides CFI.

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

#44

Post by saagarjha »

roopy wrote: 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 ¯\_(ツ)_/¯

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

#45

Post by saagarjha »

chasil wrote: post #23
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…

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.

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

#46

Post by leni536 »

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…

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

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

#47

Post by chasil »

saagarjha wrote: post #45
chasil wrote: 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.

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!

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

#48

Post by chasil »

na85 wrote: post #29
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.

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

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

#49

Post by akira2501 »

rwmj wrote: post #39

I'm curious why Theo used a new syscall. Wouldn't it be sufficient to add a new MAP_IMMUTABLE flag to mmap which would "fix" the given range of pages' mappings and protections permanently? Can't call it MAP_FIXED sadly :-)

mmap explicitly is allowed to create new maps in place of existing mappings by just freeing the underlying mapping, in fact that's one use for MAP_FIXED in safely create circularly mapped buffers.

And using MAP_IMMUTABLE with MAP_ANONYMOUS wouldn't seemingly be possible. I would think mprotect() would work, though. Since the new call works more like minherit() under the hood, he decided to just duplicate that mechanism for this.

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

#50

Post by beachhead »

saagarjha wrote: post #45
chasil wrote: 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.

Is the ROP gadget hardening OpenBSD does mostly useless tho? Can you elaborate?
Post reply on HN