I’m fairly sure NixOS Unstable also has it.
QubesOS uses debian and fedora
OpenSUSE Tumbleweed has it. The Fedora 40 beta has it. Its just a result of being bleeding edge. Arch doesn’t have exclusive rights to that.
It’s a double edged sword, fastest patches and fastest exploits.
I use arch btw
Uhh? Good for you?
Thank you
Me, using arch and fedora 40 beta, just ignoring it
Fedora got hit too.
what even is xz?
Very common compression utility for LZMA (.xz file)
Similar to .gzip, .zip, etc.
It’s definitely common, but zstd is gaining on it since in a lot of cases it can produce similarly-sized compressed files but it’s quicker to decompress them. There’s still some cases where xz is better than zstd, but not very many.
People doesn’t even know what
a rootkitXZ is, why should they care? -Sony CEO probably
It is not entirely clear either this exploit can affect other parts of the system. This is one those things you need to take extremely seriously
In the case of Arch the backdoor also wasn’t inserted into liblzma at all, because at build time there was a check to see if it’s being built on a deb or rpm based system, and only inserts it in those two cases.
See https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 for an analysis of the situation.
So even if Arch built their xz binaries off the backdoored tarball, it was never actually vulnerable.
I just know there is a lot of uncertainty. Maybe a complete wipe is a over reaction but it is better to be safe
Incorrect: the backdoored version was originally discovered by a Debian sid user on their system, and it presumably worked. On arch it’s questionable since they don’t link
sshdwithliblzma(although some say some kind of a cross-contamination may be possible via a patch used to support some systemd thingy, and systemd usesliblzma). Also, probably the rolling opensuse, and mb Ubuntu. Also nixos-unstalbe, but it doesn’t pass theargv[0]requirements and also doesn’t linkliblzma. Also, fedora.Fedora and debian was affected in beta/dev branch only, unlike arch
Unlike arch that has no “stable”. Yap, sure; idk what it was supposed to mean, tho.
Yes, but Arch, though it had the compromised package, it appears the package didn’t actually compromise Arch because of how both Arch and the attack were set up.
Sid was that dickhead in Toystory that broke the toys.
If you’re running debian sid and not expecting it to be a buggy insecure mess, then you’re doing debian wrong.
Arch has already updated XZ by relying on the source code repository itself instead of the tarballs that did have the manipulations in them.
It’s not ideal since we still rely on a potentially *otherwise* compromised piece of code still but it’s a quick and effective workaround without massive technical trouble for the issue at hand.
instead of the tarballs that did have the manipulations in them
My only exposure to Linux is SteamOS so I might be misunderstanding something, but if not:
How in the world did it get infected in the first place? Do we know?
From what I read it was one of the contributors. Looks like they have been contributing for some time too before trying to scooch in this back door. Long con.
It seems like this contributor had malicious intent the entire time they worked on the project. https://boehs.org/node/everything-i-know-about-the-xz-backdoor
Wow. That is some read.
edit:I keep thinking my jaw can’t go any closer to the floor but I keep reading and my jaw keeps dropping.
HOLY COW!
Basically, one of the contributors that had been contributing for quite some time (and was therefore partly trusted), commited a somewhat hidden backdoor. I doubt it had any effect (as it was discovered now before being pushed to any stable distro and the exploit itself didnt work on Arch) bjt we’ll have to wait for the effect to be analyzed.
Arch users are really just cannon fodder against supply chain attacks.
We’re the front line dog. Strike me down so Debian Stable’s legacy may live on.
I just did: “
rm -rf xz”pacman -Syu find / -name "*xz*" | sort | grep -e '\.xz$' | xargs -o -n1 rm -i pacman -Qqn | pacman -S -(and please, absolutely don’t run above as root. Just don’t.) I carefully answered to retain any root owned files and my backups, despite knowing the backdoor wasn’t included in the culprit package. This system has now “un-trusted” status, meaning I’ll clean re-install the OS, once the full analysis of the backdoor payload is available.
Edit: I also booted the “untrusted” system without physical access to the web, no gui, and installed the fixed package transferred to it locally. (that system is also going to be
dd if=/dev/zero'd)void doesnt have it :3
Bro WTF. How about you actually read up on the backdoor before slandering Arch. The backdoor DOES NOT affect Arch.
nixos unstable had it too: https://github.com/NixOS/nixpkgs/pull/300028
deleted by creator
I would still be cautious as the details of this exploit have not been ironed out
Arch is not vulnerable to this attack vector. Fedora Rawhide, OpenSUSE Tumbleweed and Debian Testing are.
Notice normal distros aren’t affected
tf is a normal distro?
Distros that have some sort of testing before hitting users. Arch also had the issue of killing Intel laptop displays not to long ago as well.
Maybe using the term “normal distro” is a bit of a stretch but my point is that testing is good.
Arch has regular mirrors and testing mirrors, most users use the regular ones.
In this context, I’m going to assume they mean “non-rolling-release”
Non betas/testing probably?
Windows
