[deleted]
Backdoor in upstream xz/liblzma leading to SSH server compromise
51–60 of 1001 posts
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#52Yikes! Do you have any info on the individual's background or possible motivations?
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#53Looks like Arch Linux shipped both compromised versions - and 5.6.1-2 is out to hopefully resolve it.
On arch, `ldd $(which sshd)` doesn't list lzma or xz, so I think it's unaffected? Obviously still not great to be shipping malicious code that just happens to not trigger.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#54Looks like Arch Linux shipped both compromised versions - and 5.6.1-2 is out to hopefully resolve it.
I upgraded Arch Linux on my server a few hours ago. Arch Linux does not fetch one of the compromised tarballs but builds from source and sshd does not link against liblzma on Arch. [root@archlinux ~]# pacman -Qi xz | head -n2 Name : xz Version : 5.6.1-2 [root@archlinux ~]# pacman -Qi openssh | head -n2 Name : openssh Version : 9.7p1-1 [root@archlinux ~]# ldd $(which sshd) | grep liblzma [root@archlinux ~]# It seems t…
5.6.1-1 was built from what I understand to be one of the affected tarballs. This was patched in 5.6.1-2: https://gitlab.archlinux.org/archlinux/packaging/packages/xz...
I agree on the sshd linking part.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#55Yikes! Do you have any info on the individual's background or possible motivations?
Yikes indeed. This fix is being rolled out very fast, but what about the entire rest of the codebase? And scripts? I mean, years of access? I'd trust no aspect of this code until a full audit is done, at least of every patch this author contributed.
(note: not referring to fedora here, a current fix is required. But just generally. As in, everyone is rolling out this fix, but... I mean, this codebase is poison in my eyes without a solid audit)
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#56> 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…
One of the objections that many people do not understand, is that systemd adds complexity. Unnecessary complexity. Boats full, loads full, mountains full of complexity. Yes, there are things delivered with that complexity. However, as an example, sysvinit is maybe, oh, 20k lines of code including binaries, heck including all core init scripts. What's systemd? 2M lines? It was >1M lines 4+ years ago. For an init syste…
I have a design in the works to do just this.
The problem? It's on the backburner because I don't think I could find a business model to make money from it.
I don't think offering support for a price would work, for example.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#57Yikes! Do you have any info on the individual's background or possible motivations?
I handed over all the emails I received to the security team, who I guess will send them "higher". I'll let them analyse it.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#58> 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…
Also thanks to Debian for modifying openssh.
You're not wrong. Had Debian not patched it in this way, OP might have never found it, leaving all other distros who do the same vulnerable.
Note that OP found this in Debian sid as well, which means it's highly unlikely this issue will find its way into any Debian stable systems.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#59Looks like Arch Linux shipped both compromised versions - and 5.6.1-2 is out to hopefully resolve it.
5.6.1-2 is not an attempted fix, it's just some tweaks to Arch's own build script to improve reproducibility. Arch's build script ultimately delegates to the compromised build script unfortunately, but it also appears the payload itself is specifically targeting deb/RPM based distros, so a narrow miss for Arch here.
(EDIT: as others have pointed out, part of the exploit is in the artifact from libxz, which Arch is now avoiding by switching to building from a git checkout)
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#60Looks like Arch Linux shipped both compromised versions - and 5.6.1-2 is out to hopefully resolve it.
On arch, `ldd $(which sshd)` doesn't list lzma or xz, so I think it's unaffected? Obviously still not great to be shipping malicious code that just happens to not trigger.
My Arch setup is the same, they must not patch openssh.