10 ms·

OpenBSD – pinning all system calls

197 points by g0xA52A2A 3y ago

tptacek 3y ago
Classic thread on this stuff from Halvar Flake: https://twitter.com/halvarflake/status/1156815950873804800 https://twitter.com/halvarflake/status/1156815950873804800 With that in mind, it'd be handy to know which exploit techniques these steps break, and whether those steps are in the current "meta" game for exploit developers. (The specific mitigation here: the kernel formerly locked system call invocation down to the libc.so area of program text in memory; libc.so is big, so now OpenBSD locks specific system calls down to their specified libc stubs; further, in static binaries, the same mechanism locks programs down to only those system calls used in the binary, which effectively disables all the system calls not explicitly invoked by the program text of a static binary).
- harry8 3y ago
  https://nitter.net/halvarflake/status/1156815950873804800 https://nitter.net/halvarflake/status/1156815950873804800 for those who don't have an X a/c
- vngzs 3y ago
  Indeed, in CCC's "systematic evaluation of OpenBSD's mitigations"[0] the presenter explicitly calls out OpenBSD's tendency to present mitigations without specific examples of CVEs it defeats or exploit techniques the mitigations are known to defend against: > Proper mitigations I think stem from proper design and threat modeling. Strong, reality-based statements like "this kills these vulnerabilities," or "this kills this CVE; it delays production of an exploit by one week." And also thorough testing by seasoned exploit writers. Anything else is relying on pure luck, superstition, and wishful thinking. Some of OpenBSD's mitigations are excellent and robust in defensiveness; others are amorphous and not particularly useful. [0]: https://youtu.be/3E9ga-CylWQ?feature=shared&t=2770 https://youtu.be/3E9ga-CylWQ?feature=shared&t=2770
  - zamalek 3y ago
    There have been cases where OpenBSD's hypothetical mitigations have worked out well for the project. I recall a relatively recent DNS cache poisoning attack that OpenBSD was novel in pre-emptively mitigating because something (I think it was the port?) was "needlessly" random. If a mitigation has negligible performance impact, and doesn't introduce a new attack vector, I can't imagine why it would be seen as a bad thing.
    - lmm 3y ago
      > If a mitigation has negligible performance impact, and doesn't introduce a new attack vector, I can't imagine why it would be seen as a bad thing. Because it creates confusion about your threat model, which can ultimately weaken your security.
    - insanitybit 3y ago
      Every mitigation is code and complexity. There is always a cost.
      - binkHN 3y ago
        Not for every mitigation. There are plenty of cases where OpenBSD removed code and functionality because of security implications.
        insanitybit 3y ago
        In this case we got a code exec.
  - __turbobrew__ 3y ago
    OpenBSD disabled hyperthreading before speculative execution attacks were in the wild. In the words of Greg K-H “OpenBSD was right”. There probably is some amount of security theatre in OpenBSD but they have also mitigated attacks which weren’t even known to exist.
- 0xDEAFBEAD 3y ago
  Is there a current meta for OpenBSD exploit developers? What's the right way to go about hardening the system if there's no meta to observe? My very naive take would be something like: A successful exploit depends on jumping through a number of different hoops. Each of those hoops has an estimated success probability associated with it. We can multiply all the individual probabilities together to get an estimated probability of successful exploit -- assuming that hoop probabilities are independent, which seems reasonable? The most efficient way to harden against exploits is to try and shrink whichever hoop possesses the greatest partial derivative of overall exploit success probability with respect to developer time.
  - dtx1 3y ago
    > The most efficient way to harden against exploits is to try and shrink whichever hoop possesses the greatest partial derivative of overall exploit success probability with respect to developer time. Depending on your definition of efficient, adding more hoops should work exponentially better.
    - 0xDEAFBEAD 3y ago
      My definition of efficient is essentially whatever decreases the number of workable exploits most rapidly per hour of developer time. >Depending on your definition of efficient, adding more hoops should work exponentially better. Explain?
      - nequo 3y ago
        Suppose your hoop probabilities are 25% and that you have two hoops so that the probability of jumping through both is 25% * 25% = 6.25%. You can reduce the size of one of the hoops in half, changing the probability to 25% * 25%/2 = 3.125% You can also add a third hoop, in which case the probability is 25% * 25% * 25% = 1.5625% 1.5625% < 3.125%, so adding a third hoop is better than shrinking one of the two existing hoops. Of course, this argument makes important assumptions about the hoop probabilities.
- wolverine876 3y ago
  > Classic thread on this stuff from Halvar Flake: That's from four years ago and does not address these technical issues. Are you going to pull it out every time OpenBSD is mentioned? I think people understand that you don't like their approach, etc., and the flaws you see, and that OpenBSD isn't designed for your interests.
  - rs_rs_rs_rs_rs 3y ago
    >I think people understand that you don't like their approach, etc., and the flaws you see, and that OpenBSD isn't designed for your interests. OpenBSD isn't designed from anyone's interests. https://isopenbsdsecu.re/mitigations/ https://isopenbsdsecu.re/mitigations/
    - wolverine876 3y ago
      Only if you personally get to define other people's interests. Apparently they disagree!
  - tptacek 3y ago
    "That's from four years ago" is a funny rebuttal to "classic thread".
woodruffw 3y ago
Without a pre-formed opinion: does anybody have an intuition for the security benefits this provides? My first thought is that it’s primarily mitigating cases of attacker-introduced shellcode, which should already be pretty well covered by techniques like W^X. Code reuse techniques (ROP, JOP, etc.) aren’t impacted, right? I would also think this would cause problems for JITed code, although maybe syscalls in JITed code aren’t common enough for this to be an issue (or the JIT gets around it by calling a syscall thunk, similar to how Go handled OpenBSD’s earlier syscall changes).
- gary_0 3y ago
  > Code reuse techniques (ROP, JOP, etc.) aren’t impacted, right? Unless I'm mistaken, this should restrict what you can do with ROP gadgets that contain syscalls. You will only be able to use the gadget with its intended arguments, since other syscall types will be disallowed. > I would also think this would cause problems for JITed code They can probably just jump into precompiled code that performs the needed syscall. Also, making syscalls directly from something like JITed JavaScript is generally avoided anyways. AFAIK browsers don't even let the processes that run JavaScript touch much of the system at all, instead they have to use an IPC mechanism to ask a slightly more privileged process to perform specific tasks.
  - woodruffw 3y ago
    > You will only be able to use the gadget with its intended arguments, since other syscall types will be disallowed. That makes sense, although "intended" arguments here means still being able to invoke `execve(2)`, etc., right? The gadget will still be able to mangle whatever it likes into the arguments for that syscall; it just won't be able to mangle a `wait(2)` into an `execve(2)`, I think. Your points about JITs make sense, thanks.
    - gary_0 3y ago
      Yes, that's how I understand it; you can't mangle one syscall into another, but you can still mangle the syscall's other argument values.
MyMonkeyBalls 3y ago
This implementation has a trivial buffer overflow, ROFLMAO
- tiffanyh 3y ago
  Would you mind sharing how and where in the code, specifically. Geniunely curious.
  - ninjin 3y ago
    This just went out to tech@: https://marc.info/?l=openbsd-tech&m=170234892604404&w=2 https://marc.info/?l=openbsd-tech&m=170234892604404&w=2
    - hedora 3y ago
      One of the more under-appreciated features of Rust is that it traps on integer overflow / underflow by default. It’s too bad OpenBSD doesn’t have a good Rust story for the core system. (I understand their reasoning, but it’s still too bad.) I wonder how hard it would be to backport the integer behavior to C. (C++ would be easy: Use templates.) Perhaps they could add a compiler directive that causes vanilla integer overflow/wraparound to trap, then add annotations or a special library call that supports modulo arithmetic as expected.
      - abound 3y ago
        > One of the more under-appreciated features of Rust is that it traps on integer overflow / underflow by default. I think this is only true on debug builds, with --release (which most Rust binaries an end-user uses should be compiled with) it just wraps [1] [2] [1] https://github.com/rust-lang/rfcs/blob/26197104b7bb9a5a35db243d639aee6e46d35d75/text/0560-integer-overflow.md https://github.com/rust-lang/rfcs/blob/26197104b7bb9a5a35db2... [2] https://stackoverflow.com/a/60238510 https://stackoverflow.com/a/60238510
      - ninjin 3y ago
        Look, I get as much as the next guy that Rust brings a lot of niceties. But what we are talking about here is a project that clocks in at just over 19,000,000 lines of C (`wc -l $(find src -name '*.c' -or -name '*.h')`), code heritage going back more than 40 years, an explicit commitment to a very rich set of platforms [1], and a very limited amount of manpower compared to projects such as Linux with their insane level of corporate backing. "Just rewrite it in and/or integrate Rust" is neither easy nor safe in that it overturns everything that is already there and tested. [1]: https://www.openbsd.org/plat.html https://www.openbsd.org/plat.html As for improving upon C. I can not speak for OpenBSD as a project, but I am sure that there would be ample excitement to produce a minimal, solid C compiler with experimental security features to then serve as the default compiler for the project (heck, OpenBSD already ships with a number of less common security-related compiler flags from what I recall). Sadly, I doubt there is either funding or the hands to make that a reality.
gumby 3y ago
> in ld.so text, and in that case the main program's text cannot do system calls I don’t understand this case. Is there a way to do IO in openbsd without a system call? Without IO how can you get the result of the computation? Is this a singular special case?
- monocasa 3y ago
  ld.so can do so while initially linking the application in pre main, then in > 4) in libc.so text, and ld.so tells the kernel where that is > The first 3 were cases were configured entirely by the kernel, the 4th case used a new msyscall(2) system call to identify the correct libc.so region. ld.so passes its ability to make syscalls to libc.so. The application has to call into libc.so in order to perform any IO.
  - gumby 3y ago
    Ah, makes sense, thanks. Libc can sanitize all the inputs, and as long as ld.so has a hardwired path to libc all is well. This way you don’t even need a facility to tell the kernel “this binary is allowed to make system calls.

197 points by g0xA52A2A 3y ago

Classic thread on this stuff from Halvar Flake: https://twitter.com/halvarflake/status/1156815950873804800 https://twitter.com/halvarflake/status/1156815950873804800 With that in mind, it'd be handy to know which exploit techniques these steps break, and whether those steps are in the current "meta" game for exploit developers. (The specific mitigation here: the kernel formerly locked system call invocation down to the libc.so area of program text in memory; libc.so is big, so now OpenBSD locks specific system calls down to their specified libc stubs; further, in static binaries, the same mechanism locks programs down to only those system calls used in the binary, which effectively disables all the system calls not explicitly invoked by the program text of a static binary).

harry8 3y ago
https://nitter.net/halvarflake/status/1156815950873804800 https://nitter.net/halvarflake/status/1156815950873804800 for those who don't have an X a/c
vngzs 3y ago
Indeed, in CCC's "systematic evaluation of OpenBSD's mitigations"[0] the presenter explicitly calls out OpenBSD's tendency to present mitigations without specific examples of CVEs it defeats or exploit techniques the mitigations are known to defend against: > Proper mitigations I think stem from proper design and threat modeling. Strong, reality-based statements like "this kills these vulnerabilities," or "this kills this CVE; it delays production of an exploit by one week." And also thorough testing by seasoned exploit writers. Anything else is relying on pure luck, superstition, and wishful thinking. Some of OpenBSD's mitigations are excellent and robust in defensiveness; others are amorphous and not particularly useful. [0]: https://youtu.be/3E9ga-CylWQ?feature=shared&t=2770 https://youtu.be/3E9ga-CylWQ?feature=shared&t=2770
- zamalek 3y ago
  There have been cases where OpenBSD's hypothetical mitigations have worked out well for the project. I recall a relatively recent DNS cache poisoning attack that OpenBSD was novel in pre-emptively mitigating because something (I think it was the port?) was "needlessly" random. If a mitigation has negligible performance impact, and doesn't introduce a new attack vector, I can't imagine why it would be seen as a bad thing.
  - lmm 3y ago
    > If a mitigation has negligible performance impact, and doesn't introduce a new attack vector, I can't imagine why it would be seen as a bad thing. Because it creates confusion about your threat model, which can ultimately weaken your security.
  - insanitybit 3y ago
    Every mitigation is code and complexity. There is always a cost.
    - binkHN 3y ago
      Not for every mitigation. There are plenty of cases where OpenBSD removed code and functionality because of security implications.
      - insanitybit 3y ago
        In this case we got a code exec.
- __turbobrew__ 3y ago
  OpenBSD disabled hyperthreading before speculative execution attacks were in the wild. In the words of Greg K-H “OpenBSD was right”. There probably is some amount of security theatre in OpenBSD but they have also mitigated attacks which weren’t even known to exist.
0xDEAFBEAD 3y ago
Is there a current meta for OpenBSD exploit developers? What's the right way to go about hardening the system if there's no meta to observe? My very naive take would be something like: A successful exploit depends on jumping through a number of different hoops. Each of those hoops has an estimated success probability associated with it. We can multiply all the individual probabilities together to get an estimated probability of successful exploit -- assuming that hoop probabilities are independent, which seems reasonable? The most efficient way to harden against exploits is to try and shrink whichever hoop possesses the greatest partial derivative of overall exploit success probability with respect to developer time.
- dtx1 3y ago
  > The most efficient way to harden against exploits is to try and shrink whichever hoop possesses the greatest partial derivative of overall exploit success probability with respect to developer time. Depending on your definition of efficient, adding more hoops should work exponentially better.
  - 0xDEAFBEAD 3y ago
    My definition of efficient is essentially whatever decreases the number of workable exploits most rapidly per hour of developer time. >Depending on your definition of efficient, adding more hoops should work exponentially better. Explain?
    - nequo 3y ago
      Suppose your hoop probabilities are 25% and that you have two hoops so that the probability of jumping through both is 25% * 25% = 6.25%. You can reduce the size of one of the hoops in half, changing the probability to 25% * 25%/2 = 3.125% You can also add a third hoop, in which case the probability is 25% * 25% * 25% = 1.5625% 1.5625% < 3.125%, so adding a third hoop is better than shrinking one of the two existing hoops. Of course, this argument makes important assumptions about the hoop probabilities.
wolverine876 3y ago
> Classic thread on this stuff from Halvar Flake: That's from four years ago and does not address these technical issues. Are you going to pull it out every time OpenBSD is mentioned? I think people understand that you don't like their approach, etc., and the flaws you see, and that OpenBSD isn't designed for your interests.
- rs_rs_rs_rs_rs 3y ago
  >I think people understand that you don't like their approach, etc., and the flaws you see, and that OpenBSD isn't designed for your interests. OpenBSD isn't designed from anyone's interests. https://isopenbsdsecu.re/mitigations/ https://isopenbsdsecu.re/mitigations/
  - wolverine876 3y ago
    Only if you personally get to define other people's interests. Apparently they disagree!
- tptacek 3y ago
  "That's from four years ago" is a funny rebuttal to "classic thread".

woodruffw 3y ago

Without a pre-formed opinion: does anybody have an intuition for the security benefits this provides? My first thought is that it’s primarily mitigating cases of attacker-introduced shellcode, which should already be pretty well covered by techniques like W^X. Code reuse techniques (ROP, JOP, etc.) aren’t impacted, right? I would also think this would cause problems for JITed code, although maybe syscalls in JITed code aren’t common enough for this to be an issue (or the JIT gets around it by calling a syscall thunk, similar to how Go handled OpenBSD’s earlier syscall changes).

gary_0 3y ago
> Code reuse techniques (ROP, JOP, etc.) aren’t impacted, right? Unless I'm mistaken, this should restrict what you can do with ROP gadgets that contain syscalls. You will only be able to use the gadget with its intended arguments, since other syscall types will be disallowed. > I would also think this would cause problems for JITed code They can probably just jump into precompiled code that performs the needed syscall. Also, making syscalls directly from something like JITed JavaScript is generally avoided anyways. AFAIK browsers don't even let the processes that run JavaScript touch much of the system at all, instead they have to use an IPC mechanism to ask a slightly more privileged process to perform specific tasks.
- woodruffw 3y ago
  > You will only be able to use the gadget with its intended arguments, since other syscall types will be disallowed. That makes sense, although "intended" arguments here means still being able to invoke `execve(2)`, etc., right? The gadget will still be able to mangle whatever it likes into the arguments for that syscall; it just won't be able to mangle a `wait(2)` into an `execve(2)`, I think. Your points about JITs make sense, thanks.
  - gary_0 3y ago
    Yes, that's how I understand it; you can't mangle one syscall into another, but you can still mangle the syscall's other argument values.

MyMonkeyBalls 3y ago

This implementation has a trivial buffer overflow, ROFLMAO

tiffanyh 3y ago
Would you mind sharing how and where in the code, specifically. Geniunely curious.
- ninjin 3y ago
  This just went out to tech@: https://marc.info/?l=openbsd-tech&m=170234892604404&w=2 https://marc.info/?l=openbsd-tech&m=170234892604404&w=2
  - hedora 3y ago
    One of the more under-appreciated features of Rust is that it traps on integer overflow / underflow by default. It’s too bad OpenBSD doesn’t have a good Rust story for the core system. (I understand their reasoning, but it’s still too bad.) I wonder how hard it would be to backport the integer behavior to C. (C++ would be easy: Use templates.) Perhaps they could add a compiler directive that causes vanilla integer overflow/wraparound to trap, then add annotations or a special library call that supports modulo arithmetic as expected.
    - abound 3y ago
      > One of the more under-appreciated features of Rust is that it traps on integer overflow / underflow by default. I think this is only true on debug builds, with --release (which most Rust binaries an end-user uses should be compiled with) it just wraps [1] [2] [1] https://github.com/rust-lang/rfcs/blob/26197104b7bb9a5a35db243d639aee6e46d35d75/text/0560-integer-overflow.md https://github.com/rust-lang/rfcs/blob/26197104b7bb9a5a35db2... [2] https://stackoverflow.com/a/60238510 https://stackoverflow.com/a/60238510
    - ninjin 3y ago
      Look, I get as much as the next guy that Rust brings a lot of niceties. But what we are talking about here is a project that clocks in at just over 19,000,000 lines of C (`wc -l $(find src -name '*.c' -or -name '*.h')`), code heritage going back more than 40 years, an explicit commitment to a very rich set of platforms [1], and a very limited amount of manpower compared to projects such as Linux with their insane level of corporate backing. "Just rewrite it in and/or integrate Rust" is neither easy nor safe in that it overturns everything that is already there and tested. [1]: https://www.openbsd.org/plat.html https://www.openbsd.org/plat.html As for improving upon C. I can not speak for OpenBSD as a project, but I am sure that there would be ample excitement to produce a minimal, solid C compiler with experimental security features to then serve as the default compiler for the project (heck, OpenBSD already ships with a number of less common security-related compiler flags from what I recall). Sadly, I doubt there is either funding or the hands to make that a reality.

gumby 3y ago

> in ld.so text, and in that case the main program's text cannot do system calls I don’t understand this case. Is there a way to do IO in openbsd without a system call? Without IO how can you get the result of the computation? Is this a singular special case?

monocasa 3y ago
ld.so can do so while initially linking the application in pre main, then in > 4) in libc.so text, and ld.so tells the kernel where that is > The first 3 were cases were configured entirely by the kernel, the 4th case used a new msyscall(2) system call to identify the correct libc.so region. ld.so passes its ability to make syscalls to libc.so. The application has to call into libc.so in order to perform any IO.
- gumby 3y ago
  Ah, makes sense, thanks. Libc can sanitize all the inputs, and as long as ld.so has a hardwired path to libc all is well. This way you don’t even need a facility to tell the kernel “this binary is allowed to make system calls.