12 ms·

Best would be to disable anything in sshd that can perform compression or decompression. There is no value in that capability, and way too much risk.

lifthrasiir 3y ago
Agreed on the SSH compression, but it would be not relevant to this particular vulnerability because liblzma was never used in the SSH compression anyway.
- deleted 3y ago
  [deleted]
- cpach 3y ago
  I don’t really understand the connection between liblzma and sshd, it had something do with systemd, or…?
  - lifthrasiir 3y ago
    Apparently liblzma in the compromised tarball would search for sshd functions and replace them with their own versions. This normally doesn't happen for the reason I've described, but many distros tend to compile sshd with a plugin that makes use of libsystemd, which depends on liblzma and therefore sshd will be linked with liblzma in that case. Liblzma could have done anything else it wanted, so the limited reach of this vulnerability is actually a better scenario...
  - dboreham 3y ago
    Yes.
  - cesarb 3y ago
    The connection is that sshd calls code in libsystemd when running as a systemd service, to notify systemd that it finished starting. An unrelated functionality in libsystemd (my guess is that it's related to parsing journald logs, since they can use LZMA compression) uses the lzma library, so libsystemd is linked against it. That is, the chain is: sshd is linked against libsystemd, which is linked against liblzma. When loading the sshd executable, the dynamic linker will load all these libraries. The backdoor was added to initialization code in liblzma (which runs whenever the dynamic linker loads that library). So that malicious code runs before sshd starts executing, and manipulates the dynamic linker so that it will do something (which is still being analyzed AFAIK) when some specific functions are called by the sshd executable.
    - angiosperm 3y ago
      Wow, thank you! So it is wrong for such a fundamental service as systemd to depend on such complicated processes ... just as the anti-systemd people said. Except of course shellscripts and /bin programs are just as complicated, when you check.

lifthrasiir 3y ago

Agreed on the SSH compression, but it would be not relevant to this particular vulnerability because liblzma was never used in the SSH compression anyway.

deleted 3y ago
[deleted]
cpach 3y ago
I don’t really understand the connection between liblzma and sshd, it had something do with systemd, or…?
- lifthrasiir 3y ago
  Apparently liblzma in the compromised tarball would search for sshd functions and replace them with their own versions. This normally doesn't happen for the reason I've described, but many distros tend to compile sshd with a plugin that makes use of libsystemd, which depends on liblzma and therefore sshd will be linked with liblzma in that case. Liblzma could have done anything else it wanted, so the limited reach of this vulnerability is actually a better scenario...
- dboreham 3y ago
  Yes.
- cesarb 3y ago
  The connection is that sshd calls code in libsystemd when running as a systemd service, to notify systemd that it finished starting. An unrelated functionality in libsystemd (my guess is that it's related to parsing journald logs, since they can use LZMA compression) uses the lzma library, so libsystemd is linked against it. That is, the chain is: sshd is linked against libsystemd, which is linked against liblzma. When loading the sshd executable, the dynamic linker will load all these libraries. The backdoor was added to initialization code in liblzma (which runs whenever the dynamic linker loads that library). So that malicious code runs before sshd starts executing, and manipulates the dynamic linker so that it will do something (which is still being analyzed AFAIK) when some specific functions are called by the sshd executable.
  - angiosperm 3y ago
    Wow, thank you! So it is wrong for such a fundamental service as systemd to depend on such complicated processes ... just as the anti-systemd people said. Except of course shellscripts and /bin programs are just as complicated, when you check.