4 ms·

Looks like Arch Linux shipped both compromised versions - and 5.6.1-2 is out to hopefully resolve it.

tutfbhuf 3y ago
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.
- gpm 3y ago
  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/-/commit/881385757abdc39d3cfea1c3e34ec09f637424ad https://gitlab.archlinux.org/archlinux/packaging/packages/xz... I agree on the sshd linking part.
  - tutfbhuf 3y ago
    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.
    - ComputerGuru 3y ago
      Distributions were notified under embargo.
gpm 3y ago
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.
- fullstop 3y ago
  My Arch setup is the same, they must not patch openssh.
- altairprime 3y ago
  Deleted per below
  - gpm 3y ago
    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.
    - altairprime 3y ago
      Deleted, thanks.
Macha 3y ago
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)
- gpm 3y ago
  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.
  - tutfbhuf 3y ago
    So, you suggest that Frederik Schwan had prior knowledge of the security issues but hid the real purpose of the commit under "improve reproducibility"?
    - gpm 3y ago
      Yes. I've never had to do it myself but I believe that's common practice with embargos on security vulnerabilities.
      - jethro_tell 3y ago
        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.
      - bombcar 3y ago
        It can lead to amusing cases where the intentional vuln comes in "to improve x" and the quiet fix comes in "to improve x".
mook 3y ago
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.
aquova 3y ago
The project has made an official post on the subject https://archlinux.org/news/the-xz-package-has-been-backdoored/ https://archlinux.org/news/the-xz-package-has-been-backdoore...

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.

gpm 3y ago
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/-/commit/881385757abdc39d3cfea1c3e34ec09f637424ad https://gitlab.archlinux.org/archlinux/packaging/packages/xz... I agree on the sshd linking part.
- tutfbhuf 3y ago
  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.
  - ComputerGuru 3y ago
    Distributions were notified under embargo.

gpm 3y ago

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.

fullstop 3y ago
My Arch setup is the same, they must not patch openssh.
altairprime 3y ago
Deleted per below
- gpm 3y ago
  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.
  - altairprime 3y ago
    Deleted, thanks.

Macha 3y ago

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)

gpm 3y ago
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.
- tutfbhuf 3y ago
  So, you suggest that Frederik Schwan had prior knowledge of the security issues but hid the real purpose of the commit under "improve reproducibility"?
  - gpm 3y ago
    Yes. I've never had to do it myself but I believe that's common practice with embargos on security vulnerabilities.
    - jethro_tell 3y ago
      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.
    - bombcar 3y ago
      It can lead to amusing cases where the intentional vuln comes in "to improve x" and the quiet fix comes in "to improve x".

mook 3y ago

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.

aquova 3y ago

The project has made an official post on the subject https://archlinux.org/news/the-xz-package-has-been-backdoored/ https://archlinux.org/news/the-xz-package-has-been-backdoore...