PLEASE. I keep seeing it in memes. As I understand it the latest version of the xz package (present in rolling release distros like Arch and SUSE Tumbleweed) has “a backdoor”, but I have no earthly clue what can be done by malicious folks with access to that backdoor or if I should be afraid or how to check if my distro is compromised or how to prevent damage if it is or (…)

  • @[email protected]
    link
    fedilink
    English
    308 months ago

    Fairly simple explanation by arstechnica: “The malicious versions [of xz], researchers said, intentionally interfere with authentication performed by SSH, a commonly used protocol for connecting remotely to systems. SSH provides robust encryption to ensure that only authorized parties connect to a remote system. The backdoor is designed to allow a malicious actor to break the authentication and, from there, gain unauthorized access to the entire system. The backdoor works by injecting code during a key phase of the login process.”

    Also from the article, you should check if your distro is offering a downgrade from the affected 5.6.x packages. Right now the exploit is not fully understood. For example, openSUSE recommends a full reinstall of Tumbleweed if an SSH server was enabled, just to mitigate risk.

    https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/

    https://news.opensuse.org/2024/03/29/xz-backdoor/

    • Count Regal InkwellOP
      link
      fedilink
      English
      9
      edit-2
      8 months ago

      I was on EndeavourOS (Arch-derived), but switched to SUSE Tumbleweed like, this weekend.

      But hold up

      So if the backdoor is all about exploiting ssh to gain full system access, and ssh was never enabled in my OS I’m in the clear regardless?

      • @[email protected]
        link
        fedilink
        English
        88 months ago

        Just to be sure, you should check whether SSHD is enabled: sudo systemctl status sshd.service If you never enabled it and it’s disabled+inactive, then no need to reinstall Tumbleweed per the current guidance. Also you can double check your version of xz to make sure it’s downgraded, the downgraded version for Tumbleweed should look like this:

        sudo zypper search -vi xz
        Loading repository data...
        Reading installed packages...
        
        S  | Name | Type    | Version               | Arch   | Repository
        ---+------+---------+-----------------------+--------+------------------
        i+ | xz   | package | 5.6.1.revertto5.4-3.2 | x86_64 | update-tumbleweed
            name: xz
        
        • qaz
          link
          English
          18 months ago

          What if it was enabled but it was disabled in the firewall so it could only be used from the device itself?

      • @theit8514
        link
        English
        58 months ago

        While the full extent of the exploit is not fully known, it seems specifically targeted at the sshd binary on deb and rpm based systems. If you’ve got that service disabled it should not have been running actively on your system. You should still perform whatever is needed to downgrade, but I would say you’re in the clear.

          • @theit8514
            link
            English
            18 months ago

            Each distribution is different but Arch has stated that they did have the exploit artifact in their version of xz but the artifact was not loaded into memory with sshd as their process does not link sshd with liblzma library.

            More details below but highly recommend upgrade/downgrade anyways to remove the exploit code version.

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

    • @[email protected]
      link
      fedilink
      English
      58 months ago

      Right now the exploit is not fully understood.

      How so, btw? The original maintainer and everyone else can read the changed code, so how can it not be fully understood? Is it that heavily obfuscated, or…?

      • @Ptsf
        link
        English
        68 months ago

        The backdoor was not contained within the source code, but within precompiled binary blobs sent “downstream” from the maintainer, this is often done so that end users get a leaner version of the software without development tool chains attached, which also makes automated checking of these blobs difficult to impossible so instead we rely on verified and trusted upstream maintainers to be “good actors”. That’s the reason this is such a big wakeup call, as it’s a maintainer that worked on projects and waited for years before trying to push this through.