3 ms·

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 mas

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.
- rigid 3y ago
  > login process RCE doesn't really follow a login process design. As soon as you got RCE you can be considered pwned. If not now, then at the time the next locally exploitable vulnerability comes up. There are plenty.
- nrdvana 3y ago
  Or better, just make an ssh without any dependencies. Statically compile it, and get rid of the libssl and libsystemd and even libpam and libc's nsswitch. (I actually do this for some of my systems)

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.

rigid 3y ago
> login process RCE doesn't really follow a login process design. As soon as you got RCE you can be considered pwned. If not now, then at the time the next locally exploitable vulnerability comes up. There are plenty.
nrdvana 3y ago
Or better, just make an ssh without any dependencies. Statically compile it, and get rid of the libssl and libsystemd and even libpam and libc's nsswitch. (I actually do this for some of my systems)