Looks like Arch Linux shipped both compromised versions - and 5.6.1-2 is out to hopefully resolve it.
Backdoor in upstream xz/liblzma leading to SSH server compromise
21–30 of 1001 posts
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#22Very strange behavior from the upstream developers. Possible government involvement? I have a feeling LANG is checked to target servers from particular countries
One thing to note is that the person that added the commits only started contributing around late 2022 and appears to have a Chinese name. Might be required by law to plant the backdoor.
That would be quite scary considering they have contributed to a wide variety of projects including C++ https://learn.microsoft.com/en-us/cpp/overview/whats-new-cpp...
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#23> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma. The systemd notification protocol could have been as simple as just writing a newline to a pipe, but instead you have to link to the libsystemd C library, so now security-critical daemons like openssh have additional dependencies like liblzma loaded…
FWIW, I did a quick check on a Devuan system.
The sshd in Devuan does link to a libsystemd stub - this is to cut down on their maintenance of upstream packages.
However that stub does not link to lzma.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#24Safety through obscurity and weirdness! If you disable ifunc, like any sensible person, this backdoor disables itself.
I'm curious now. What is ifunc? (Had difficulty finding it through a search)
ifunc is a GNU method of interposing function calls with platform-optimized versions of the function. It is used to detect CPU features at runtime and insert, for example, AVX2-optimized versions of memcmp. It is seen in crypto a lot, because CPUs have many crypto-specific instructions.
However, I don't like it much and I think software should be compiled for the target machine in the first place. My 1 hardened system that is reachable from the public network is based on musl, built mostly with llvm, and with ifunc disabled.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#25> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma. The systemd notification protocol could have been as simple as just writing a newline to a pipe, but instead you have to link to the libsystemd C library, so now security-critical daemons like openssh have additional dependencies like liblzma loaded…
> The systemd notification protocol could have been as simple as just writing a newline to a pipe
It basically is. libsystemd links to liblzma for other features not related to notifications.
(The protocol is that systemd passes the path to a unix socket in the `NOTIFY_SOCKET` env variable, and the daemon writes "READY=1" into it.)
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#26Homebrew is currently shipping 5.6.1 (and was shipping 5.6.0 as well). Hopefully not affected on mac?
The issue is caused by patches to add integration with systemd, so no, this won't affect SSH on a Mac.
Just because macs don't use systemd, doesn't mean the backdoor won't work. The oss-sec post talks about liblzma having backdoors in crc32_resolve() and crc64_resolve() and that it has not been fully reversed. This could perhaps affect more than just sshd on x86-64 linux?
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#27NixOS/Pkgs 23.11 unaffected, unstable contains backdoored implementations (5.6.0, 5.6.1) but their OpenSSH sshd does not seem to link against systemd/liblzma, and the backdoor doesn't get configured in (only happens on .deb/.rpm systems).
It may not have really mattered much for NixOS:
> b) argv[0] needs to be /usr/sbin/sshd
For once, the lack of FHS interoperability is a benefit, if only on accident.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#28That's completely crazy, the backdoor is introduced through a very cryptic addition to the configure script. Just looking at the diff, it doesn't look malicious at all, it looks like build script gibberish.
It looks like an earlier commit with a binary blob "test data" contained the bulk of the backdoor, then the configure script enabled it, and then later commits patched up valgrind errors caused by the backdoor. See the commit links in the "Compromised Repository" section.
Also, seems like the same user who made these changes are still submitting changes to various repositories as of a few days ago. Maybe these projects need to temporarily stop accepting commits until further review is done?
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#29Safety through obscurity and weirdness! If you disable ifunc, like any sensible person, this backdoor disables itself.
I'm curious now. What is ifunc? (Had difficulty finding it through a search)
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#30So many security companies publishing daily generic blog posts about "serious supply chain compromises" in various distros on packages with 0 downloads, and yet it takes a developer debugging performance issues to find an actual compromise. I worked in the software supply chain field and cannot resist feeling the entire point of that industry is to make companies pay for a security certificate so you can shift the bl…
> cannot resist feeling the entire point of that industry is to make companies pay for a security certificate so you can shift the blame onto someone else when things go wrong.
That's the entire point. You did everything you could by getting someone else look at it and saying it's fine.