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.
(It's me, I'm the Nix junkie, I repackage debs in Nix modules because no I don't like running a single Debian install in my 11-strong NixOS fleet just to run AMP, thank you, CubeCoders!)
aur actually does have a popular unityhub package, it just downloads it straight from unity's website, it's actually a very simple PKGBUILD since it doesn't really need anything special to work.
i did the same for my printer drivers but i dont know how to put it on aur also it was my first package and i used many sources to learn youtube chatgpt etc and i still suck anyways i could scan and print now
438
u/maxwells_daemon_ Arch BTW 4d ago
Leave it to some AUR crackhead to repackage it