Arch Linux - News: The xz package has been backdoored
archlinux.org
      • Laser@feddit.de
        0·
        6 months ago

        Debian is not really the problem, but rather the target, just read the original announcement at https://www.openwall.com/lists/oss-security/2024/03/29/4:

        == Affected Systems ==
Running as part of a debian or RPM package build:
if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64";then
...
openssh does not directly use liblzma. However debian and several other
distributions patch openssh to support systemd notification, and libsystemd
does depend on lzma.


Initially starting sshd outside of systemd did not show the slowdown, despite
the backdoor briefly getting invoked. This appears to be part of some
countermeasures to make analysis harder.

Observed requirements for the exploit:
a) TERM environment variable is not set
b) argv[0] needs to be /usr/sbin/sshd
c) LD_DEBUG, LD_PROFILE are not set
d) LANG needs to be set
e) Some debugging environments, like rr, appear to be detected. Plain gdb
   appears to be detected in some situations, but not others

        So if you were using Arch, you were unaffected by this vulnerability because

        • the script wouldn’t trigger because it uses neither DEB nor RPM packages
        • even if it had triggered, the backdoor only gets activated when the calling binary is /usr/sbin/sshdwhich doesn’t happen in Arch because they don’t patch OpenSSH to support systemd (which in turn pulls in xz).

        This doesn’t mean that Arch saved you because it’s super secure or anything, but this was a supply chain attack that hit Arch (and Debian Sid, where the backdoor was actually caught because ssh logins took so long…), but it didn’t trigger because it wasn’t targeted.

        Meaning there’s no immediate need to be concerned, but you should update ASAP even though the Arch package probably doesn’t contain backdoored artifacts.

  • xvlc@feddit.deEnglish
    0·
    6 months ago

    Simply excluding this backdoor does not seem to be sufficient. The malicious actor has contributed over 750 commits to xz, all of which could contain further backdoors.

    Downgrading to the last version without any contributions from the malicious actor is not possible either, because of new functionalities and other security issues that were fixed in the meantime. Uninstalling xz is also not possible, because half my system depends on it.

    I guess it will take some time to sort all of that out. I am very impressed by the fast and coordinated response to this incident by the FOSS community.

    • Fubarberry@sopuli.xyzOPEnglish
      0·
      6 months ago

      This is just speculation, but I think this was a long planned attack. I think it’s unlikely any previous backdoors or significant security vulnerabilities would have been introduced, the goal was to establish themselves as a legitimate contributor and then sneak one critical backdoor in unnoticed. Sneaking in multiple vulnerabilities would have increased the risk of detection.

      From what I understand they did cause a conflict with another package, and then used that to try to justify having the backdoored versions of the package fast tracked into upcoming Debian and fedora releases. But that would also suggest that their whole goal was shipping this one backdoor.

    • Shayeta@feddit.deEnglish
      0·
      6 months ago

      This backdoor has existed for the past 2 months. If anything, Arch was one of the first to roll out the fix.