Backdoor in upstream xz/liblzma leading to SSH server compromise
601–610 of 1001 posts
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#602Very annoying - the apparent author of the backdoor was in communication with me over several weeks trying to get xz 5.6.x added to Fedora 40 & 41 because of it's "great new features". We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added). We had to race last night to fix the problem after an inadvertent break of the embargo. He has been part of the xz proj…
GitHub has suspended @JiaT75's account. EDIT: Lasse Collin's account @Larhzu has also been suspended. EDIT: Github has disabled all Tukaani repositories, including downloads from the releases page. -- EDIT: Just did a bit of poking. xz-embedded was touched by Jia as well and it appears to be used in the linux kernel. I did quick look and it doesn't appear Jia touched anything of interest in there. I also checked the…
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#603I agree with the lzip guy
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#604Maybe it's finally time to start sunsetting LZMA and xz all together in favor of newer algorithms like Zstandard that also offer better performance but compression rates on par with LZMA.
Yes but don’t start thinking they’re immune to compromise
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#605> 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…
That is all the protocol is. From https://www.freedesktop.org/software/systemd/man/latest/sd_n... : > These functions send a single datagram with the state string as payload to the socket referenced in the $NOTIFY_SOCKET environment variable. The simplest implementation (pseudocode, no error handling, not guaranteed to compile), is something like: const char *addrstr = getenv("NOTIFY_SOCKET"); if (addrstr) { int fd =…
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#606Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#607> 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…
That is all the protocol is. From https://www.freedesktop.org/software/systemd/man/latest/sd_n... : > These functions send a single datagram with the state string as payload to the socket referenced in the $NOTIFY_SOCKET environment variable. The simplest implementation (pseudocode, no error handling, not guaranteed to compile), is something like: const char *addrstr = getenv("NOTIFY_SOCKET"); if (addrstr) { int fd =…
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#608Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#609Yikes! Do you have any info on the individual's background or possible motivations?
I would presume it's a state actor. Generally in the blackhat world, attackers have very precise targets. They want to attack this company or this group of individuals. But someone who backdoors such a core piece of open source infrastructure wants to cast a wide net to attack as many as possible. So that fits the profile of a government intelligence agency who is interested in surveilling, well, everything. Or it co…
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#610Earlier quoted context omitted.
And, Joey Hess has counted at least 750 commits to xz from that handle. https://hachyderm.io/@joeyh/112180715824680521 This does not look trust-inspiring. If the code is complex, there could be many more exploits hiding.
Anyone have any level of confidence that for example EL7/8 would not be at risk even if more potential exploits at play?