The security advisory makes it sound as if this is not a big problem because it’s in a sandboxed process, which at worst runs in a empty chroot as an unprivileged user. On FreeBSD, I believe it uses Capsicum to have basically no access other than the IPC channel to the parent. On OpenBSD, it uses pledge to achieve similar rights. On Darwin, it uses the sandbox framework to drop all access to the filesystem. There seems to be a seccomp-bpf back end as well, but as with all seccomp-bpf things it’s almost impossible to tell what it actually permits, but I presume that’s the default in Linux distros?
It’s not clear what harm being able to insert malicious replies into those IPC message channels would be. Can it permit authorisation with an invalid key, for example?
I guess that the fallback (chroot) model, if it’s shipped anywhere, would allow an attacker to make outbound network connections originating from the ssh server, which would be enough to bypass ssh jump hosts, but I don’t think this is possible with any of the other sandbox implementations.
I posted this mainly because of the OpenBSD malloc bypass in the update reply. I’m curious to see if they’ll be able to go through the other 2 steps they’ve listed on an unpatched system.
I’m also curious to see if there will be any adjustments made to OpenBSD’s malloc due to this.
I’m not really surprised by the malloc hardening bypass. None of these things are robust, they just increase work factor for the attacker. We have a couple of mitigations in snmalloc for this kind of thing:
We make the free lists a queue, rather than a stack, so that there’s a longer time before reuse (and so reuse is less deterministic).
We store the next pointer in the free lists as a simple permutation of the value in the previous one, making it hard for an attacker to overwrite a dangling object with something that will look valid to us.
Both of these make it harder to turn a UAF into a reproducible exploit, but both can be bypassed with sufficient effort. The fact that we return frees from other threads to the originating allocator makes it hard, in a multithreaded program, to predict where an object will be reused, but you may still be able to get something with a moderately high probability of success. The free list hardening can be bypassed if you can leak a few adjacent dangling pointers on the same free list, which is possible if you can shape the heap (I.e. if the attacker can influence allocation and deallocation patterns).
OpenBSD’s malloc is somewhat more aggressive in optimising for security rather than performance, but it is still running on a substrate that isn’t memory safe. In the simple case, an arbitrary information-disclosure vulnerability (such as a usable spectre gadget) will leak all of the secrets that their (or our) mitigations depend on.
That doesn’t mean that they’re worthless: making an attacker do more work is often worth it. If an attacker has only a 5% probability of being able to use an exploit (for example) then it’s hard for a worm to spread.
The security advisory makes it sound as if this is not a big problem because it’s in a sandboxed process, which at worst runs in a empty chroot as an unprivileged user. On FreeBSD, I believe it uses Capsicum to have basically no access other than the IPC channel to the parent. On OpenBSD, it uses pledge to achieve similar rights. On Darwin, it uses the sandbox framework to drop all access to the filesystem. There seems to be a seccomp-bpf back end as well, but as with all seccomp-bpf things it’s almost impossible to tell what it actually permits, but I presume that’s the default in Linux distros?
It’s not clear what harm being able to insert malicious replies into those IPC message channels would be. Can it permit authorisation with an invalid key, for example?
I guess that the fallback (chroot) model, if it’s shipped anywhere, would allow an attacker to make outbound network connections originating from the ssh server, which would be enough to bypass ssh jump hosts, but I don’t think this is possible with any of the other sandbox implementations.
Even before the sandbox step, you’d still need to 1. Know where to jump. 2. Be allowed to jump there.
Fortunately we’re still a few steps before talking about potential IPC/network issues.
I posted this mainly because of the OpenBSD malloc bypass in the update reply. I’m curious to see if they’ll be able to go through the other 2 steps they’ve listed on an unpatched system.
I’m also curious to see if there will be any adjustments made to OpenBSD’s malloc due to this.
I’m not really surprised by the malloc hardening bypass. None of these things are robust, they just increase work factor for the attacker. We have a couple of mitigations in snmalloc for this kind of thing:
Both of these make it harder to turn a UAF into a reproducible exploit, but both can be bypassed with sufficient effort. The fact that we return frees from other threads to the originating allocator makes it hard, in a multithreaded program, to predict where an object will be reused, but you may still be able to get something with a moderately high probability of success. The free list hardening can be bypassed if you can leak a few adjacent dangling pointers on the same free list, which is possible if you can shape the heap (I.e. if the attacker can influence allocation and deallocation patterns).
OpenBSD’s malloc is somewhat more aggressive in optimising for security rather than performance, but it is still running on a substrate that isn’t memory safe. In the simple case, an arbitrary information-disclosure vulnerability (such as a usable spectre gadget) will leak all of the secrets that their (or our) mitigations depend on.
That doesn’t mean that they’re worthless: making an attacker do more work is often worth it. If an attacker has only a 5% probability of being able to use an exploit (for example) then it’s hard for a worm to spread.
Well, this settles my curiosity a bit: https://marc.info/?l=openbsd-tech&m=167673316325935&w=2
There are more updates at the link provided. I know I’m bumping my own thread but this fascinates me.
Direct to another update from Qualys: https://seclists.org/oss-sec/2023/q1/109
And another from OpenBSD malloc: https://marc.info/?l=openbsd-tech&m=167715187212393&w=2