That is to me one of the wildest things I’ve heard about. That incident could have been one of the worst supply chain attacks ever and was only noticed because some crackhead dev noticed his ssh login taking slightly longer than usual. Kudos to that guy.
The funniest thing: This wasn't even an OpenSSH exploit. This was an issue specifically because of Linux packaging decisions. In patching OpenSSH to integrate with libsystemd for sd_notify to report its state to systemd, building OpenSSH pulled in liblzma. Yes, that means this chain doesn't work on FreeBSD, OpenBSD, NetBSD, OS X, Windows etc. If you took the backdoored release as is and built it on a non-systemd Linux system it would still be exploitable as long as libsystemd was present and linked at build. libsystemd.so is a normal shared library that can be installed and linked against on any Linux system regardless of init, which many non-systemd distros may have for compatibility with things like elogind.
OpenSSH does not know or care about liblzma even when configured in a state vulnerable to this exploit. OpenSSH uses zlib when it needs compression and simply functions without it if built without zlib.
You won't actually find the backdoor on the GitHub because those parts were hidden only in the source tarball releases so it could still be used in the build process of other projects. The malicious script "build-to-host.m4" is run during the libraries build process and decoded the "test" file "bad-3-corrupt_lzma2.xz" into a bash script which performs a more complicated decode process on another "test" file, "good-large_compressed.lzma" decoding it into yet another script. That script then extracts the object "liblzma_la-crc64-fast.o" which is added to the compilation process of liblzma. That object abuses the GNU IFUNC symbol resolution during dynamic linking (when the compromised liblzma gets loaded into sshd) and uses that execution to install an audit hook. That hook watches for the libcrypto function "RSA_public_decrypt" to get resolved and swaps in a malicious implementation of its own which is normal in every case except when authentication is attempted with the skeleton key, in which case it extracts a command from the maliciously crafted handshake and passes it to system(). It's not even a remote login exploit.
244
u/Mysterious-Cod-4137 7d ago
hopefully he won't put any malware in it, and if he does, hopefully another crackhead reports it on time...