4 ms·

https://lwn.net/Articles/806776/ https://lwn.net/Articles/806776/ says, system-call-origin verification is for mitigation of ROP. ROP is (always?) a result of s

https://lwn.net/Articles/806776/ https://lwn.net/Articles/806776/ says, system-call-origin verification is for mitigation of ROP. ROP is (always?) a result of stack buffer overflows, which are a result of bad programming in asm/C/C++, but usually not a thing at all with modern languages like Go, Rust, Swift, Haskell, etc. while C/C++-programs usually use the libc already. This enforces programs written in such languages to use another layer, written in C, that is not really necessary but might introduce new vulnerabilities. Do I miss something?

roblabla 6y ago
The system call interface is usually written in an unsafe language such as asm anyways. Going through the libc is very unlikely to actually introduce vulnerabilities, especially if going through the lowest level function that directly wrap the syscall. Not using the libc was always a risky proposition on BSDs anyways. They don't have a stable kernel ABI the same way the Linux kernel does. From OpenBSD's perspective, the stable ABI is the libc, and anything using the kernel ABI directly is liable for breakage with each update.
- loosescrews 6y ago
  > Going through the libc is very unlikely to actually introduce vulnerabilities Citation needed. glibc has a long history of security bugs. https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.html https://www.cvedetails.com/vulnerability-list/vendor_id-72/p...
  - lxgr 6y ago
    To quote the grandparent post: > especially if going through the lowest level function that directly wrap the syscall. I think the argument is that security bugs are unlikely to occur in those low-level wrappers.
  - roblabla 6y ago
    Geez man, way to take things out of context. Let me fix your quote: > Going through the libc is very unlikely to actually introduce vulnerabilities, especially if going through the lowest level function that directly wrap the syscall. Sure, glibc has a bunch of bugs. But the lowest level of functions, that just wrap the syscalls, are very unlikely to have bugs. Here's the `read` implementation, for instance: https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d8c7d79c4c95c72c1b/sysdeps/unix/sysv/linux/read.c#L24 https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d... All it does is delegate to the low-level syscall, with some extra handling around to handle async calls (which can be removed when compiling glibc yourself, but you're probably not doing this). Here's clone: https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d8c7d79c4c95c72c1b/sysdeps/unix/sysv/linux/x86_64/clone.S#L50 https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d... This one's written in asm, and you can't really simplify it all that much more. All the functions that wrap the low-level syscalls are very hard to get wrong, really. Where the glibc bugs come from are the high-level functions, like pthread. But those can trivially be bypassed if necessary.
    - sivizius 6y ago
      And where is the advantage then to have a `call syscall_wrapper` over `mov rax, syscall_number; syscall` if the ROP was able to return just before the call?
      - roblabla 6y ago
        I wasn't making any claim on whether this mitigation is actually useful, I was simply stating it's unlikely to introduce more vulnerabilities than the status quo. But since you're asking, I can think of two upsides: 1. It restricts the kernel attack surface available to only those syscalls that are exposed through the wrapper. (This is obviously dubious if the libc provides a generic syscall function, I don't know if OpenBSD libc has one). 2. It forces the ROP to either find the libc ASLR base, or to find a gadget that calls into the target libc function. This makes ROPs a lot harder to write. As with any mitigations, they're mostly meant to make the attacker's life miserable. They're not full protections, and can often be bypassed. The point is to increase the cost of the attack.
  - warmwaffles 6y ago
    Other libc implementations exist that do not have many. Musl[1] for one. [1] https://www.cvedetails.com/product/39652/Musl-libc-Musl.html?vendor_id=16859 https://www.cvedetails.com/product/39652/Musl-libc-Musl.html...
    - sivizius 6y ago
      The number of CVEs is for the most part a function of how-often-does-someone-look-at-it and only for a tiny part a function of safety. If I remember correctly, sometime ago a lot of CVEs appeared for OpenBSD, because someone seemed to have started looking for vulnerabilities and found a lot of quite trivial but severe ones. Therefore I am somewhat concerned about the the OpenBSD-libc, but neither have I looked at the code nor am I an expert. I see the point that the wrappers are probably safe, but yet the full libc is loaded and available for malicious code. But to be fair: The libc is able to handle – either by caching or by implementing the functionality – some syscalls without actually invoking a syscall and such a library allows to have an unstable API for syscalls and might allow other mitigation tactics. As a compromise: Why not multiple libraries (libc, libgo?, librs?) that are allowed to do syscalls? Yes, a larger code base to maintain but imho enforcing a single library is worse.
      - roblabla 6y ago
        At least for rust, a librs would be hard to create due to the lack of a stable ABI. So even if you did a pure rust libstd (like the now defunct Steed[0]), you'd still need to either manually link that libc (breaking the mitigation), or rebuild your program each time the distro updates either libstd or the rust compiler. I'm not sure what the situation for Go is. Assuming Go has proper support for dynamic loading and a stable ABI, it would be doable. [0]: https://github.com/japaric/steed https://github.com/japaric/steed
        steveklabnik 6y ago
        You could expose the C ABI from your Rust code, which is, of course, stable. You would want to do that for a libc, even if a Rust ABI were available.

roblabla 6y ago

The system call interface is usually written in an unsafe language such as asm anyways. Going through the libc is very unlikely to actually introduce vulnerabilities, especially if going through the lowest level function that directly wrap the syscall. Not using the libc was always a risky proposition on BSDs anyways. They don't have a stable kernel ABI the same way the Linux kernel does. From OpenBSD's perspective, the stable ABI is the libc, and anything using the kernel ABI directly is liable for breakage with each update.

loosescrews 6y ago
> Going through the libc is very unlikely to actually introduce vulnerabilities Citation needed. glibc has a long history of security bugs. https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.html https://www.cvedetails.com/vulnerability-list/vendor_id-72/p...
- lxgr 6y ago
  To quote the grandparent post: > especially if going through the lowest level function that directly wrap the syscall. I think the argument is that security bugs are unlikely to occur in those low-level wrappers.
- roblabla 6y ago
  Geez man, way to take things out of context. Let me fix your quote: > Going through the libc is very unlikely to actually introduce vulnerabilities, especially if going through the lowest level function that directly wrap the syscall. Sure, glibc has a bunch of bugs. But the lowest level of functions, that just wrap the syscalls, are very unlikely to have bugs. Here's the `read` implementation, for instance: https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d8c7d79c4c95c72c1b/sysdeps/unix/sysv/linux/read.c#L24 https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d... All it does is delegate to the low-level syscall, with some extra handling around to handle async calls (which can be removed when compiling glibc yourself, but you're probably not doing this). Here's clone: https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d8c7d79c4c95c72c1b/sysdeps/unix/sysv/linux/x86_64/clone.S#L50 https://github.com/bminor/glibc/blob/21c3f4b5368686ade28d90d... This one's written in asm, and you can't really simplify it all that much more. All the functions that wrap the low-level syscalls are very hard to get wrong, really. Where the glibc bugs come from are the high-level functions, like pthread. But those can trivially be bypassed if necessary.
  - sivizius 6y ago
    And where is the advantage then to have a `call syscall_wrapper` over `mov rax, syscall_number; syscall` if the ROP was able to return just before the call?
    - roblabla 6y ago
      I wasn't making any claim on whether this mitigation is actually useful, I was simply stating it's unlikely to introduce more vulnerabilities than the status quo. But since you're asking, I can think of two upsides: 1. It restricts the kernel attack surface available to only those syscalls that are exposed through the wrapper. (This is obviously dubious if the libc provides a generic syscall function, I don't know if OpenBSD libc has one). 2. It forces the ROP to either find the libc ASLR base, or to find a gadget that calls into the target libc function. This makes ROPs a lot harder to write. As with any mitigations, they're mostly meant to make the attacker's life miserable. They're not full protections, and can often be bypassed. The point is to increase the cost of the attack.
- warmwaffles 6y ago
  Other libc implementations exist that do not have many. Musl[1] for one. [1] https://www.cvedetails.com/product/39652/Musl-libc-Musl.html?vendor_id=16859 https://www.cvedetails.com/product/39652/Musl-libc-Musl.html...
  - sivizius 6y ago
    The number of CVEs is for the most part a function of how-often-does-someone-look-at-it and only for a tiny part a function of safety. If I remember correctly, sometime ago a lot of CVEs appeared for OpenBSD, because someone seemed to have started looking for vulnerabilities and found a lot of quite trivial but severe ones. Therefore I am somewhat concerned about the the OpenBSD-libc, but neither have I looked at the code nor am I an expert. I see the point that the wrappers are probably safe, but yet the full libc is loaded and available for malicious code. But to be fair: The libc is able to handle – either by caching or by implementing the functionality – some syscalls without actually invoking a syscall and such a library allows to have an unstable API for syscalls and might allow other mitigation tactics. As a compromise: Why not multiple libraries (libc, libgo?, librs?) that are allowed to do syscalls? Yes, a larger code base to maintain but imho enforcing a single library is worse.
    - roblabla 6y ago
      At least for rust, a librs would be hard to create due to the lack of a stable ABI. So even if you did a pure rust libstd (like the now defunct Steed[0]), you'd still need to either manually link that libc (breaking the mitigation), or rebuild your program each time the distro updates either libstd or the rust compiler. I'm not sure what the situation for Go is. Assuming Go has proper support for dynamic loading and a stable ABI, it would be doable. [0]: https://github.com/japaric/steed https://github.com/japaric/steed
      - steveklabnik 6y ago
        You could expose the C ABI from your Rust code, which is, of course, stable. You would want to do that for a libc, even if a Rust ABI were available.