4 ms·

You could refactor sshd so most network payload processing is delegated to sandboxed sub-processes. Then an RCE there has less capabilities to exploit directly.

You could refactor sshd so most network payload processing is delegated to sandboxed sub-processes. Then an RCE there has less capabilities to exploit directly. But, I think you would have to assume an RCE can cause the sub-process to produce wrong answers. So if the answers are authorization decisions, you can transitively turn those wrong answers into RCE in the normal login or remote command execution context. But, the normal login or remote command execution is at least audited. And it might have other enforcement of which accounts or programs are permitted. A configuration disallowing root could not be bypassed by the sub-process. You could also decide to run all user logins/commands under some more confined SE-Linux process context. Then, the actual user sessions would be sandboxed compared to the real local root user. Of course, going too far with this may interfere with the desired use cases for SSH.

asveikau 3y ago
I thought that OpenSSH's sshd already separates itself into a privileged process and a low-privilege process. I don't know any details about that. Here's what Google showed me for that: https://github.com/openssh/openssh-portable/blob/master/README.privsep https://github.com/openssh/openssh-portable/blob/master/READ...
- treasy 3y ago
  If you look at the diagram of privsep, the authentication process is part of the privileged binary, which is where this RCE lives http://www.citi.umich.edu/u/provos/ssh/priv.jpg http://www.citi.umich.edu/u/provos/ssh/priv.jpg
  - cryptonector 3y ago
    The signature validation could be moved into an unprivileged process forked from that one.
    - littlestymaar 3y ago
      That's an easy thing to say after the fact indeed but yes. In fact after such a disastrous backdoor I wouldn't be surprised if OpenSSH moved all code calling external libraries to unprivileged processes to make sure such an attack can never have such a dramatic effect (an auth bypass would still likely be possible, but that's still way better than a root RCE…). At this point “All libraries could be malicious” is a threat model that must be considered for something as security critical as OpenSSH.
      - asveikau 3y ago
        I don't think that's a threat model that OpenSSH should waste too much time on. Ultimately this is malicious code in the build machine compiling a critical system library. That's not reasonable to defend against. Keep in mind that upstream didn't even link to liblzma. Debian patched it to do so. OpenSSH should defend against that too?
        CanaryLayout 3y ago
        any one of us if we sat on the OSSH team would flip the middle finger. What code is the project supposed to write when nothing on main dyn loaded liblzma. It was brought in from a patch they don't have realistic control over. This is a Linux problem, and the problem is systemd, which is who brought the lib into memory and init'd it.
        shzhdbi09gv8ioi 3y ago
        > This is a Linux problem, and the problem is systemd, which is who brought the lib into memory and init'd it. Not at all, it is a distro issue because a few distros such as Debian chose to patch openssh to bring in systemd support [1]. Other systemd-based distros like Arch Linux remains unaffected because they don't carry this patch. 1: https://sources.debian.org/src/openssh/1%3A9.7p1-2/debian/patches/systemd-readiness.patch/ https://sources.debian.org/src/openssh/1%3A9.7p1-2/debian/pa...
nrdvana 3y ago
That just raises the hurdle for the attacker. The attacker in this case has full control to replace any function within ssh with their own version, and the master process of sshd will always need the ability to fork and still be root on the child process before dropping privileges. I don't see any way around that. They only needed to override one function this time, but if you raise the bar they would just override more functions and still succeed.
- lovasoa 3y ago
  > The attacker in this case has full control to replace any function within ssh with their own version Not true. They have this ability only for binaries that are linked to liblzma. If sshd were to be decomposed into multiple processes, not all of them would (hopefully) depend on all the libraries that the original sshd depended on.
  - nrdvana 3y ago
    Well, sshd doesn't depend on liblzma in the first place, but Debian and RedHat thought it would be a good idea to tie it into libsystemd for logging purposes, and patched in support. It's still pretty bad to have systemd compromised, even if ssh weren't, though. Maybe the army of pitchforks should be marching on the systemd camp. It's definitely not OpenBSD's choice of architecture, here.
- tomasGiden 3y ago
  I’m highly safety critical systems you have software (and hardware) diversity were multiple pieces of software, developed independently, have to vote on the result. Maybe highly critical pieces of Linux like the login process should be designed the same way. So that two binaries without common dependencies would need to accept the login for the user to get privileges. Exactly how to do it (especially transparently for the user), I have no idea though. Maybe sending ssh login requests to two different sshd implementations and if they don’t do the same things (same system calls), they are both killed. Or some kind of two step login process where the first login only gives access to the sandbox of the second login process. But in general I assume the Linux attack surface is too big to do software diversity for all of it.

asveikau 3y ago

I thought that OpenSSH's sshd already separates itself into a privileged process and a low-privilege process. I don't know any details about that. Here's what Google showed me for that: https://github.com/openssh/openssh-portable/blob/master/README.privsep https://github.com/openssh/openssh-portable/blob/master/READ...

treasy 3y ago
If you look at the diagram of privsep, the authentication process is part of the privileged binary, which is where this RCE lives http://www.citi.umich.edu/u/provos/ssh/priv.jpg http://www.citi.umich.edu/u/provos/ssh/priv.jpg
- cryptonector 3y ago
  The signature validation could be moved into an unprivileged process forked from that one.
  - littlestymaar 3y ago
    That's an easy thing to say after the fact indeed but yes. In fact after such a disastrous backdoor I wouldn't be surprised if OpenSSH moved all code calling external libraries to unprivileged processes to make sure such an attack can never have such a dramatic effect (an auth bypass would still likely be possible, but that's still way better than a root RCE…). At this point “All libraries could be malicious” is a threat model that must be considered for something as security critical as OpenSSH.
    - asveikau 3y ago
      I don't think that's a threat model that OpenSSH should waste too much time on. Ultimately this is malicious code in the build machine compiling a critical system library. That's not reasonable to defend against. Keep in mind that upstream didn't even link to liblzma. Debian patched it to do so. OpenSSH should defend against that too?
      - CanaryLayout 3y ago
        any one of us if we sat on the OSSH team would flip the middle finger. What code is the project supposed to write when nothing on main dyn loaded liblzma. It was brought in from a patch they don't have realistic control over. This is a Linux problem, and the problem is systemd, which is who brought the lib into memory and init'd it.
        shzhdbi09gv8ioi 3y ago
        > This is a Linux problem, and the problem is systemd, which is who brought the lib into memory and init'd it. Not at all, it is a distro issue because a few distros such as Debian chose to patch openssh to bring in systemd support [1]. Other systemd-based distros like Arch Linux remains unaffected because they don't carry this patch. 1: https://sources.debian.org/src/openssh/1%3A9.7p1-2/debian/patches/systemd-readiness.patch/ https://sources.debian.org/src/openssh/1%3A9.7p1-2/debian/pa...

nrdvana 3y ago

That just raises the hurdle for the attacker. The attacker in this case has full control to replace any function within ssh with their own version, and the master process of sshd will always need the ability to fork and still be root on the child process before dropping privileges. I don't see any way around that. They only needed to override one function this time, but if you raise the bar they would just override more functions and still succeed.

lovasoa 3y ago
> The attacker in this case has full control to replace any function within ssh with their own version Not true. They have this ability only for binaries that are linked to liblzma. If sshd were to be decomposed into multiple processes, not all of them would (hopefully) depend on all the libraries that the original sshd depended on.
- nrdvana 3y ago
  Well, sshd doesn't depend on liblzma in the first place, but Debian and RedHat thought it would be a good idea to tie it into libsystemd for logging purposes, and patched in support. It's still pretty bad to have systemd compromised, even if ssh weren't, though. Maybe the army of pitchforks should be marching on the systemd camp. It's definitely not OpenBSD's choice of architecture, here.
tomasGiden 3y ago
I’m highly safety critical systems you have software (and hardware) diversity were multiple pieces of software, developed independently, have to vote on the result. Maybe highly critical pieces of Linux like the login process should be designed the same way. So that two binaries without common dependencies would need to accept the login for the user to get privileges. Exactly how to do it (especially transparently for the user), I have no idea though. Maybe sending ssh login requests to two different sshd implementations and if they don’t do the same things (same system calls), they are both killed. Or some kind of two step login process where the first login only gives access to the sandbox of the second login process. But in general I assume the Linux attack surface is too big to do software diversity for all of it.