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

11–20 of 72 posts

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

#11

Post by eqvinox »

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 mapping, or changing the mapping attributes (primarily RWX).

Even if some userland process requires an executable stack, that would be indicated with ELF flags and set up by the loader - and then frozen in place.

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

#12

Post by brynet »

jart wrote: post #9

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

There was some work done on XOM (eXecute-only-memory) for arm64, but on at least x86 there isn't a separate page table bit for just read permissions, so there's no way[0][1] to express R^X, PROT_EXEC without PROT_READ is not possible.

Amusingly the 80286 supported execute-only segments, but this was dropped from 32-bit x86.

[0] It is possible on Intel in VM guests using EPT (Extended Page Tables), mlarkin@ experimented with protecting the host kernel in a special VM, called "Underjack". AMD SVM supports nothing like this.

[1] The custom AMD APU SoC in Sony's PS5 console supports "xotext" via NDA'd extensions, but there's no public documentation. (If _anyone_ knows details, pls share)

... btw, PROT_WRITE-only mappings are also impossible on x86 as well, so PROT_WRITE implicitly means PROT_READ. Not that I'm aware of any valid reason anyone might want this.

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

#13

Post by saagarjha »

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

This happens to already exist on macOS as VM_FLAGS_PERMANENT when setting up the mapping.

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

#14

Post by staticassertion »

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

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

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

#15

Post by saagarjha »

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…

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

You’ve just described why system call integrity is useless without strong CFI :)

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

#18

Post by fsckboy »

bell-cot wrote: post #5
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

+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

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

#19

Post by landr0id »

alberth wrote: post #3

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

Different. These are enhanced mitigations to detect when a program is calling into the kernel from a weird state that should never happen in a well-formed program. It basically prevents certain types of exploits from successfully calling into the kernel.

*the new mitigation just makes user-mode memory completely immutable. You can never "upgrade" a page's permissions or change its contents after it's been marked as immutable.

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

#20

Post by geraldcombs »

alberth wrote: post #3

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

As a more general question, is there a resource available that shows which memory protection schemes are available on various OSes? It'd be nice to see what the state of the art is on Linux, macOS, the BSDs, etc. in one place.
Post reply on HN