6 ms·

OpenBSD System-Call Pinning

129 points by rwmj 3y ago

tptacek 3y ago
System call pinning has been a classic example of an OpenBSD approach to exploit mitigation that exploit developers dunk on; a thread just a couple months ago: https://news.ycombinator.com/item?id=38579913 https://news.ycombinator.com/item?id=38579913 I think? this is the same work, just now merged into the kernel?
- steveklabnik 3y ago
  There is a paragraph in the article dedicated to this, starting with: > Security researchers have expressed doubt about how useful this check is at preventing compromises. Doesn't cite the HN thread, but two other cases. > I think? this is the same work, just now merged into the kernel? That is my understanding, yes. From the article: > In December, De Raadt sent a patch to the OpenBSD mailing list expanding OpenBSD's restrictions on the locations from which a process can make system calls. ... Now that patch has been merged, finishing a process which De Raadt said has taken five years.
- PrimeMcFly 3y ago
  > a classic example of an OpenBSD approach to exploit mitigation that exploit developers dunk on Part of why it is hard to take its reputation as as security focused OS seriously.
  - irdc 3y ago
    In their defence, the OpenBSD developers do put their mon^H^H^Htime where their mouth is and release their work even with dubious features included. How much those features actually matter, instead of how much expert opinion says they matter, can then be judged in the wild. Failed experiments are also a good part of research.
    - PrimeMcFly 3y ago
      What can also be judged is ignoring expert advice in favor of rolling their own inferior solutions.
      - user3939382 3y ago
        Whose and what expert advice did they ignore?
        falserum 3y ago
        Mine (statistically at least; I am a random internet person, who does not contribute to any OS development)
        PrimeMcFly 3y ago
        Exploit developers telling them their mitigations won't do anything, for starters.
- yjftsjthsd-h 3y ago
  Has that "dunking" manifested in actual exploits?
  - tptacek 3y ago
    I dunno. Has it?
    - yjftsjthsd-h 3y ago
      Well since https://www.openbsd.org/ https://www.openbsd.org/ still says > Only two remote holes in the default install, in a heck of a long time! I'm assuming not, but I could always be mistaken.
      - opnitro 3y ago
        This is a _very_ qualified statement. The default OpenBSD install enables an extremely small amount of services by default, which is why they can claim that. I'm not saying that's wrong, or a bad idea, but obviously a platform that doesn't enable many network services is going to have a small amount of remote holes. this is on top of a lot of very careful programming and interesting security research, and this post isn't meant to take anything away from the OpenBSD devs.
        wolverine876 3y ago
        > The default OpenBSD install enables an extremely small amount of services by default, which is why they can claim that. Probably this issue has been hashed out many times over the decades, but arguably the security gain isn't a fortunate or incidental benefit of minimizing default enabled services, nor a cheat like weighted dice, it's a very real benefit resulting from an effective, intentional technique. Maybe other OSes should do the same, and then everyone would have that benefit. The other OSes have other priorities, and that's fine. Embrace that. Yes, most users (and developers) don't want to deal with the compatibility issues. But when you say OpenBSD has few default security holes because they have few default services, that's a complement.
o11c 3y ago
From comments: > avoiding [...] errno Note that errno can be optimized by a sufficiently smart compiler, simply by treating it as a register, then annotating various functions with whether it is preserved, clobbered, or conditionally used for return. The libc boundary is quite annoying though; for this case in particular, that it doesn't expose the fact that errno is at a fixed offset from the TLS register. And generally, libc is vehemently opposed to the existence of smart compilers, since all libc calls are expected to be treated as opaque barriers.
- IAmLiterallyAB 3y ago
  > And generally, libc is vehemently opposed to the existence of smart compilers Yes, as far as I'm aware none of the major libcs on Linux support LTO
- gpderetta 3y ago
  well, yes, but you need whole-program compilation.
- deleted 3y ago
  [deleted]
yobert 3y ago
> The direct-syscalls-inside-the-binary model used by go (and only go, noone else in the history of the unix software does this) provided the biggest resistance against this effort". I know this annoys unix people. But I have to say I actually really like that Go shakes this up. I believe the C function monopoly just isn't healthy for things. You should be able to make a new completely unrelated language. The Go developers were the first in a long time to do this, not because they are stupid, but because they were ambitious.
- steveklabnik 3y ago
  My hot take here is that this split exists because of the way that Linux development works differently than other Unices and other operating systems. Essentially, it's an example of Conway's Law. As always, things are about API boundaries: what is internal to you, and what is exposed externally to your users. With Linux, well, we all know the rms copypasta: "I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux." This is a joke, but it also points to something real and serious: Linux, being just a kernel, means that they provide a stable kernel API. glibc, being written by a different organization, builds on top of that API and adds its own stable API. By contrast, many other operating systems are developed as a full operating system. They don't produce a kernel as a standalone component. As such, they choose some other sort of boundary as the API for the OS. On unices, that's often the libc. On Windows, that's the Windows API, of which win32 is an example. There are good reasons to not make the kernel your API boundary. Different systems make different choices, and that's a good thing, not a bad thing.
  - akira2501 3y ago
    > There are good reasons to not make the kernel your API boundary. Good reasons for the developers, not so much for the end users.
    - steveklabnik 3y ago
      I don't agree that those two things are at odds.
philsnow 3y ago
> Both [msyscall and pinsyscall] can only be invoked once by a given process, which is done by the dynamic linker. How are/were static executables handled? I’m a little fuzzy on how execve notices that a given executable is dynamic (and needs ld.so to run it) or static (in which case.. it just jumps to the _start symbol?). If the dynamic linker isn’t involved, what calls msyscall/pinsyscall?
- philsnow 3y ago
  Ah, found a good discussion of how it works in Linux https://eli.thegreenplace.net/2012/08/13/how-statically-linked-programs-run-on-linux https://eli.thegreenplace.net/2012/08/13/how-statically-link... Is it materially different in openbsd?
brynet 3y ago
Library relinking, mimmutable(2), xonly, along with other recent developments such as the removal of indirect syscall(2), make syscall pinning all the more interesting, and raise the bar against attackers significantly. One can only hope that more will eventually find its way into Linux, like with how paid employees at Google have been spending the past ~6 months cloning mimmutable (which HN characters decried as "useless") to make mseal() for defending Chrome. https://marc.info/?l=linux-kernel&w=2&r=1&s=mseal&q=b https://marc.info/?l=linux-kernel&w=2&r=1&s=mseal&q=b
- saagarjha 3y ago
  mimmutable, given a proper security model, doesn't seem useless. Lots of people have adopted something like this; Chrome is trying to bring it to Linux but Apple has been shipping a similar VM_FLAGS_PERMANENT for the last two years or so, which I believe even predates mimmutable making it to OpenBSD. In general, mitigations can raise the bar against attackers, but they don't have to. Determining whether it does can be pretty difficult, especially to those who come up with mitigations ;)
  - brynet 3y ago
    > Lots of people have adopted something like this; Really? And how many systems have made any effort to use it, on OpenBSD most of a programs static address space is now automatically immutable (main program .text, ld.so .text, .bss, main stack, dymamically-loaded shared libraries, and dlopen()'d libraries mapped w/ RTLD_NODELETE. Nobody else have done the work on a complete operating system.
    - saagarjha 3y ago
      Question for you: why do you do this? "We made most of the address space immutable" is, by itself, not a useful property security-wise. What analysis did you do to arrive at it being necessary? I mean this as a genuine question but pose it in the context of what everyone else is doing. You're basically going "nobody else did this properly" because others did a different implementation. In other operating systems at least they go "oh we saw a chain that targeted xyz structure in this page and modified it so we are going to make sure it is really immutable". How did OpenBSD arrive at the conclusion that what other people are doing doesn't actually confer the full security benefit?
tiffanyh 3y ago
Doesn’t macOS do something like this.
- comex 3y ago
  It does not.
marshray 3y ago
"Another benefit is that it requires unique methodology for OpenBSD, which requirements investment." Secure in the absence of an attacker? This part: xx: b8 05 00 00 00 mov $0x5,%eax xx: 0f 05 syscall This means "perform operation #5, which is open(2)" Inside the kernel, we know the system call # and the address of the syscall instruction. Why can't the attacker just jump to an existing syscall instruction? Maybe one followed soon by a return. 4) in libc.so's table, all the system call stub "syscall instructions" are registered. I don't know a lot about binary exploitation techniques. Is all this entirely reliant on layout randomization?
- projektfu 3y ago
  Yeah, but the memory shouldn't be readable, so it's harder to find the random location to jump to. There's a bit of circular discussion, where Theo/Open BSD devs say they're introducing feature F to reduce an exploit, and people criticize it as being irrelevant because you can do other exploits, but they've already implemented A,B,C,D and E to handle those, and for each of those individual features there's a list of exploits that get around them, but maybe not if all are implemented. A more rigorous analysis of the security environment as a whole would be useful.
onetimeuse92304 3y ago
> Security researchers have expressed doubt about how useful this check is at preventing compromises. Well... if they are able to craft a call to a syscall from some random piece of memory you are already f-d and this little hurdle is at most going to be an annoyance.
- deleted 3y ago
  [deleted]

129 points by rwmj 3y ago

System call pinning has been a classic example of an OpenBSD approach to exploit mitigation that exploit developers dunk on; a thread just a couple months ago: https://news.ycombinator.com/item?id=38579913 https://news.ycombinator.com/item?id=38579913 I think? this is the same work, just now merged into the kernel?

steveklabnik 3y ago
There is a paragraph in the article dedicated to this, starting with: > Security researchers have expressed doubt about how useful this check is at preventing compromises. Doesn't cite the HN thread, but two other cases. > I think? this is the same work, just now merged into the kernel? That is my understanding, yes. From the article: > In December, De Raadt sent a patch to the OpenBSD mailing list expanding OpenBSD's restrictions on the locations from which a process can make system calls. ... Now that patch has been merged, finishing a process which De Raadt said has taken five years.
PrimeMcFly 3y ago
> a classic example of an OpenBSD approach to exploit mitigation that exploit developers dunk on Part of why it is hard to take its reputation as as security focused OS seriously.
- irdc 3y ago
  In their defence, the OpenBSD developers do put their mon^H^H^Htime where their mouth is and release their work even with dubious features included. How much those features actually matter, instead of how much expert opinion says they matter, can then be judged in the wild. Failed experiments are also a good part of research.
  - PrimeMcFly 3y ago
    What can also be judged is ignoring expert advice in favor of rolling their own inferior solutions.
    - user3939382 3y ago
      Whose and what expert advice did they ignore?
      - falserum 3y ago
        Mine (statistically at least; I am a random internet person, who does not contribute to any OS development)
      - PrimeMcFly 3y ago
        Exploit developers telling them their mitigations won't do anything, for starters.
yjftsjthsd-h 3y ago
Has that "dunking" manifested in actual exploits?
- tptacek 3y ago
  I dunno. Has it?
  - yjftsjthsd-h 3y ago
    Well since https://www.openbsd.org/ https://www.openbsd.org/ still says > Only two remote holes in the default install, in a heck of a long time! I'm assuming not, but I could always be mistaken.
    - opnitro 3y ago
      This is a _very_ qualified statement. The default OpenBSD install enables an extremely small amount of services by default, which is why they can claim that. I'm not saying that's wrong, or a bad idea, but obviously a platform that doesn't enable many network services is going to have a small amount of remote holes. this is on top of a lot of very careful programming and interesting security research, and this post isn't meant to take anything away from the OpenBSD devs.
      - wolverine876 3y ago
        > The default OpenBSD install enables an extremely small amount of services by default, which is why they can claim that. Probably this issue has been hashed out many times over the decades, but arguably the security gain isn't a fortunate or incidental benefit of minimizing default enabled services, nor a cheat like weighted dice, it's a very real benefit resulting from an effective, intentional technique. Maybe other OSes should do the same, and then everyone would have that benefit. The other OSes have other priorities, and that's fine. Embrace that. Yes, most users (and developers) don't want to deal with the compatibility issues. But when you say OpenBSD has few default security holes because they have few default services, that's a complement.

o11c 3y ago

From comments: > avoiding [...] errno Note that errno can be optimized by a sufficiently smart compiler, simply by treating it as a register, then annotating various functions with whether it is preserved, clobbered, or conditionally used for return. The libc boundary is quite annoying though; for this case in particular, that it doesn't expose the fact that errno is at a fixed offset from the TLS register. And generally, libc is vehemently opposed to the existence of smart compilers, since all libc calls are expected to be treated as opaque barriers.

IAmLiterallyAB 3y ago
> And generally, libc is vehemently opposed to the existence of smart compilers Yes, as far as I'm aware none of the major libcs on Linux support LTO
gpderetta 3y ago
well, yes, but you need whole-program compilation.
deleted 3y ago
[deleted]

yobert 3y ago

> The direct-syscalls-inside-the-binary model used by go (and only go, noone else in the history of the unix software does this) provided the biggest resistance against this effort". I know this annoys unix people. But I have to say I actually really like that Go shakes this up. I believe the C function monopoly just isn't healthy for things. You should be able to make a new completely unrelated language. The Go developers were the first in a long time to do this, not because they are stupid, but because they were ambitious.

steveklabnik 3y ago
My hot take here is that this split exists because of the way that Linux development works differently than other Unices and other operating systems. Essentially, it's an example of Conway's Law. As always, things are about API boundaries: what is internal to you, and what is exposed externally to your users. With Linux, well, we all know the rms copypasta: "I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux." This is a joke, but it also points to something real and serious: Linux, being just a kernel, means that they provide a stable kernel API. glibc, being written by a different organization, builds on top of that API and adds its own stable API. By contrast, many other operating systems are developed as a full operating system. They don't produce a kernel as a standalone component. As such, they choose some other sort of boundary as the API for the OS. On unices, that's often the libc. On Windows, that's the Windows API, of which win32 is an example. There are good reasons to not make the kernel your API boundary. Different systems make different choices, and that's a good thing, not a bad thing.
- akira2501 3y ago
  > There are good reasons to not make the kernel your API boundary. Good reasons for the developers, not so much for the end users.
  - steveklabnik 3y ago
    I don't agree that those two things are at odds.

philsnow 3y ago

> Both [msyscall and pinsyscall] can only be invoked once by a given process, which is done by the dynamic linker. How are/were static executables handled? I’m a little fuzzy on how execve notices that a given executable is dynamic (and needs ld.so to run it) or static (in which case.. it just jumps to the _start symbol?). If the dynamic linker isn’t involved, what calls msyscall/pinsyscall?

philsnow 3y ago
Ah, found a good discussion of how it works in Linux https://eli.thegreenplace.net/2012/08/13/how-statically-linked-programs-run-on-linux https://eli.thegreenplace.net/2012/08/13/how-statically-link... Is it materially different in openbsd?

brynet 3y ago

Library relinking, mimmutable(2), xonly, along with other recent developments such as the removal of indirect syscall(2), make syscall pinning all the more interesting, and raise the bar against attackers significantly. One can only hope that more will eventually find its way into Linux, like with how paid employees at Google have been spending the past ~6 months cloning mimmutable (which HN characters decried as "useless") to make mseal() for defending Chrome. https://marc.info/?l=linux-kernel&w=2&r=1&s=mseal&q=b https://marc.info/?l=linux-kernel&w=2&r=1&s=mseal&q=b

saagarjha 3y ago
mimmutable, given a proper security model, doesn't seem useless. Lots of people have adopted something like this; Chrome is trying to bring it to Linux but Apple has been shipping a similar VM_FLAGS_PERMANENT for the last two years or so, which I believe even predates mimmutable making it to OpenBSD. In general, mitigations can raise the bar against attackers, but they don't have to. Determining whether it does can be pretty difficult, especially to those who come up with mitigations ;)
- brynet 3y ago
  > Lots of people have adopted something like this; Really? And how many systems have made any effort to use it, on OpenBSD most of a programs static address space is now automatically immutable (main program .text, ld.so .text, .bss, main stack, dymamically-loaded shared libraries, and dlopen()'d libraries mapped w/ RTLD_NODELETE. Nobody else have done the work on a complete operating system.
  - saagarjha 3y ago
    Question for you: why do you do this? "We made most of the address space immutable" is, by itself, not a useful property security-wise. What analysis did you do to arrive at it being necessary? I mean this as a genuine question but pose it in the context of what everyone else is doing. You're basically going "nobody else did this properly" because others did a different implementation. In other operating systems at least they go "oh we saw a chain that targeted xyz structure in this page and modified it so we are going to make sure it is really immutable". How did OpenBSD arrive at the conclusion that what other people are doing doesn't actually confer the full security benefit?

tiffanyh 3y ago

Doesn’t macOS do something like this.

comex 3y ago
It does not.

marshray 3y ago

"Another benefit is that it requires unique methodology for OpenBSD, which requirements investment." Secure in the absence of an attacker? This part: xx: b8 05 00 00 00 mov $0x5,%eax xx: 0f 05 syscall This means "perform operation #5, which is open(2)" Inside the kernel, we know the system call # and the address of the syscall instruction. Why can't the attacker just jump to an existing syscall instruction? Maybe one followed soon by a return. 4) in libc.so's table, all the system call stub "syscall instructions" are registered. I don't know a lot about binary exploitation techniques. Is all this entirely reliant on layout randomization?

projektfu 3y ago
Yeah, but the memory shouldn't be readable, so it's harder to find the random location to jump to. There's a bit of circular discussion, where Theo/Open BSD devs say they're introducing feature F to reduce an exploit, and people criticize it as being irrelevant because you can do other exploits, but they've already implemented A,B,C,D and E to handle those, and for each of those individual features there's a list of exploits that get around them, but maybe not if all are implemented. A more rigorous analysis of the security environment as a whole would be useful.

onetimeuse92304 3y ago

> Security researchers have expressed doubt about how useful this check is at preventing compromises. Well... if they are able to craft a call to a syscall from some random piece of memory you are already f-d and this little hurdle is at most going to be an annoyance.

deleted 3y ago
[deleted]