Hacker News Reader

Comment by fourfour3 | Hacker News Reader

Looks 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)

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"?

Yes.

I've never had to do it myself but I believe that's common practice with embargos on security vulnerabilities.

It can lead to amusing cases where the intentional vuln comes in "to improve x" and the quiet fix comes in "to improve x".

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.

5.6.1 is masked specifically.

Also, https://mastodon.social/@mgorny@treehouse.systems/1121802382... from a Gentoo dev mentions that Gentoo doesn't use the patch that results in sshd getting linked against liblzma.

As far as I know this is not an official communication channel so don't take it as such.

This is very likely the case. Arch maintainers do get early information on CVEs just like any other major distro.

But with pacman/makepkg 6.1 (which recently released) git sources can also now be check summed IIRC which is a funny coincidence.

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 that Arch Linux is not affected.

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.

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.

Distributions were notified under embargo.

The project has made an official post on the subject

https://archlinux.org/news/the-xz-package-has-been-backdoore...

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.

My Arch setup is the same, they must not patch openssh.

Deleted per below

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.

Deleted, thanks.

Reply on news.ycombinator.com