4 ms·
It does not. OpenSSH pulled in libsystemd to provide startup notification. Libsystemd pulled in liblzma. No code from liblzma normally ends up in OpenSSH. But
by Tuna-Fish 3y ago
It does not.
OpenSSH pulled in libsystemd to provide startup notification. Libsystemd pulled in liblzma. No code from liblzma normally ends up in OpenSSH. But because it is built as a dependency for libsystemd, it's build scripts are ran in the same environment as libsystemd, and OpenSSH.
The attack payload was hidden as an obfuscated binary blob in the liblzma tests directory, masqueraded as a compression test case. When lzma was compiled from the git sources, generating the build scripts using autotools, nothing untoward was done. But lzma was also provided as a source tarball that was used by distro packagers, that had the autotools already ran. The attacker replaced the autogenerated, unreadable script output with one that checked if liblzma was being compiled in the same environment as OpenSSH and if it was being compiled so that it was going to end up as a .deb or .rpm package, and if both were true, embed the attack payload into OpenSSH.
Then the attack payload started with a lot of checks, including testing whether OpenSSH was being started normally by init scripts or manually, and for the presence of usual debugging tools, and only attached the payload to the running process if it seemed like a "natural" bootup with no running debugging tools. When running, the payload hooked into private key verification, and if the correct private key attempted to login, the payload would take the rest of the incoming packet and call system with it, that is, provide remote code execution as root.
- filmor 3y agoThe build scripts of OpenSSH are irrelevant. The malicious code is embedded on building an rpm or deb for liblzma itself and becomes active when the dynamic library is loaded. There is a recent PR for systemd that instead of linking to the compressors during build dlopen-s them when used (https://github.com/systemd/systemd/pull/31550 https://github.com/systemd/systemd/pull/31550) which disables this particular path, but any initial load of a backdoored liblzma makes sshd exploitable (see https://lwn.net/ml/oss-security/20240329155126.kjjfduxw2yrlxgzm@awork3.anarazel.de/ https://lwn.net/ml/oss-security/20240329155126.kjjfduxw2yrlx..., section "Analyzing the injected code"). Lennart Poettering stated on a mailing list that e.g. libselinux als links liblzma and ends up in a lot of services on SELinux-enabled systems.
- Denvercoder9 3y ago> with one that checked if liblzma was being compiled in the same environment as OpenSSH No, the attack didn't check for OpenSSH at build time, it checked whether it was injected into the ssh process at runtime.
- dboreham 3y ago> pulled in libsystemd to provide startup notification This seems sort of fine (although...why can't said notification be done by writing simple text to a pipe/file/socket?), but the library shouldn't be some kitchen-sink thing that links to the universe of attack surface.
- growse 3y agoThe notification can be done by sending some data to $NOTIFY_SOCKET. That's all sd_notify does.
- marcosdumay 3y agoNotice that the protocol specification is way more complex than that, and already changed since systemd was released. All the library does is sending some data through the socket, but that's not at all what the docs tell you to do.
- growse 3y agoThe docs could be better, sure, but where did this idea what "interfaces can never be changed" come from?
- marcosdumay 3y agoIt comes from the idea that your computer shouldn't stop working at random. But surely, what is needed is "interfaces can never be changed without redefining your project in a way that makes absolutely obvious it's incompatible with its past". Systemd fails that one too.
- queuebert 3y agoEven more, why can't information like this be passed up the call chain as integer return codes? That scheme has been a perfectly functional for decades, all the way back to at least BSD's rc scripts, maybe before.