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)
Are you sure about that? The diff moves away from using the compromised tarballs to the not-compromised (by this) git source. The comment message says it's about reproducibility, but especially combined with the timing it looks to me like that was just to avoid breaking an embargo.
So, you suggest that Frederik Schwan had prior knowledge of the security issues but hid the real purpose of the commit under "improve reproducibility"?
And, If you break the embargo too many times then you just find out with the rest of us and that's not a great way to run a distro. I believe openbsd is or was in that position around the time of the intel speculative execution bugs.
xz was masked in the Gentoo repositories earlier today with the stated reason of "Investigating serious bug". No mention of security. It's pretty likely.
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 ~]#
Interesting, they just switched from tarballs to source 19 hours ago. It seems to me that Frederik Schwan had prior knowledge of the security issue, or it is just a rare coincidence.
The writeup indicates that the backdoor only gets applied when building for rpm or deb, so Arch probably would have been okay either way? Same with Nix, Homebrew, etc.
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.
This is what the `detect_sh.bin` attached to the email does. I can only assume that the pesron who reported the vulnerability checked that this succeeds in detecting it.
Note that I'm not looking for the vulnerable symbols, I'm looking for the library that does the patching in the first place.
