from Hacker News

OpenBSD may soon gain further memory protections: immutable userland mappings

by fcambus on 9/2/22, 3:06 PM with 69 comments

  • by kyledrake on 9/2/22, 4:04 PM

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

  • by teknopurge on 9/2/22, 5:23 PM

    I'm not adding insight to this thread, but I love the OpenBSD project. Theo and the team are goat engineers and industry advocates.

  • by alberth on 9/2/22, 4:52 PM

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

  • by rwmj on 9/2/22, 7:06 PM

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

  • by roopy on 9/2/22, 5:57 PM

    What exploit technique is this mitigating?

  • by staticassertion on 9/2/22, 5:05 PM

    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.

  • by jart on 9/2/22, 5:24 PM

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

  • by dang on 9/2/22, 6:17 PM

    Url changed from https://undeadly.org/cgi?action=article;sid=20220902100648, which points to this.