On Tue, 2 Apr 2024, Colin Watson wrote: [I'm not subscribed to the debian-* lists, please Cc me in replies if you want me to see them] > [I've CCed openssh-unix-dev for awareness, but set Mail-Followup-To to > just debian-devel and debian-ssh to avoid potentially spamming them > with a long discussion. If you choose to override this then that's > your call, but please be mindful of upstream's time.] Thanks Colin for considering how to reduce dependency chains for sshd. I just remembered that this is not the first time that sshd has been attacked via a transitive library dependency - it has happened before, about 10 years ago: https://www.welivesecurity.com/2014/02/21/an-in-depth-analysis-of-linuxebury/ Attacks like these are impossible for sshd to defend against itself. Instead we have to look to minimising the number of libraries that end up in sshd's address space, especially that of the privileged sshd process. We are currently exploring splitting sshd into separate binaries for the listener, privileged monitor, pre- and post-auth network-facing processes so that each can be reduced in size and functionality to the minimum possible. This should remove a number of dependencies from the privileged process. There's a draft of these changes at https://github.com/djmdjm/openssh-wip/pull/26 but it's OpenBSD-only at this stage. We're likely to proceed with splitting the listener process from the rest of sshd hopefully before the next release. Another thing we're considering in OpenSSH is changing how we integrate with PAM. PAM's API demands loading modules into the authenticating process' address space, but obviously we've just been reminded that this is risky. I think that I would prefer to move to a model where there PAM auth and account modules run in a helper process, and only the session module runs in the unprivileged post-auth sshd process. This means that PAM auth/account modules and their transitive library dependencies cannot affect the sshd address space. They would still likely need to run with privilege, could still fail permissively in unwanted situations and might still be able to cause problems directly (e.g. opening a reverse shell from the PAM module itself), but they would no longer have direct access to the contents of sshd network traffic, signatures, etc that are extremely useful in building NOBUS (https://en.wikipedia.org/wiki/NOBUS) backdoors like the xv one. Where this gets challenging is that some PAM modules make assumptions that the auth, account and session modules all run in the same address space. These would break until re-architected to pass things explicitly, e.g. via environment variables, temp files, etc. Time permitting, I'll get a prototype of these changes made for wider experimentation. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
