And you know what? Doing updates once a week saved me from updating to this version :)
I upgraded to 5.6.0-1 on the 28th Februar already. Over a month ago. On a server. That’s the first time Arch testing has fucked me so hard lol.
You probably are fairly safe. Yeah, okay, from a purely-technical standpoint, your server was wide-open to the Internet. But unless some third party managed to identify and leverage the backdoor in the window between you deploying it and it being fixed, only the (probably state-backed) group who are doing this would have been able to make use of it. They probably aren’t going to risk exposing their backdoor by exploiting it on your system unless they believe that you have something that would be really valuable to them.
Maybe if you’re a critical open-source developer, grabbing your signing keys or other credentials might be useful, given that they seem to be focused on supply-chain attacks, but for most people, they probably just aren’t worth the risk. Only takes them hitting some system with an intrusion-detection system that picks up on the breakin, them leaving behind traces, and some determined person tracking down what happened, and they’ve destroyed their exploit.
Damn fine work all around.
I know this is an issue fraught with potential legal and political BS, and it’s impossible to check everything without automation these days, but is there an organization that trains and pays people to work as security researchers or QA for open source projects?
Basically, a watchdog group that finds exploitable security vulnerabilities, and works with individuals or vendors to patch them? Maybe make it a publicly owned and operated group with mandatory reporting of some kind. An international project funded by multiple governments, where it’s harder for a single point of influence to hide exploits, abuse secrets, or interfere with the researchers? They don’t own or control any code, just find security issues and advise.
I don’t know.
Just thinking that modern security is getting pretty complicated, with so many moving parts and all.
t y for sharing.
#showerthoughts The problem is in upstream and has only entered Debian Sid/unstable. Does this mean that for example bleeding edge Arch (btw) sshd users are compromised already ?
Here’s a link to the PR for anyone who’s interested
Looks like the 5.6.1-2 release on Arch moved from using the published GitHub releases to just using the git repository directly, which as I understand avoids the exploit (because the obfuscated script to inject the exploit is only present in the packaged tarballs and not the git repo itself)
They also believe we (Arch users) are unaffected because this backdoor targeted Debian and Redhat type packaging specifically and also relied on a certain SSH configuration Arch doesn’t use. To be honest while it’s nice to know we’re unaffected, it’s not at all comforting that had the exploiter targeted Arch they would have succeeded. Just yesterday I was talking to someone about how much I love rolling release distros and now I’m feeling insecure about it.
More details here: https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/issues/2
Someone always has to be the guinea pig.
That being said, maybe there’s an argument for distros that do rolling releases to have an “intentionally delayed rolling release” that just trails the regular rolling release by a fixed amount of time to provide more time for guinea pigs to run into things. If you want rolling, but can live with the delay, just use that.
Arch is on 5.6.1 as of now: https://archlinux.org/packages/core/x86_64/xz/
We at Nixpkgs have barely evaded having it go to a channel used by users and we don’t seem to be affected by the backdoor.
Arch had a patch rolled out yesterday [1][2][3] that switches to the git repo. On top of that the logic in the runtime shim and build script modifier was orchestrated to target Debian and RPM build systems and environments [4].
[2] https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/issues/2
[3] https://security.archlinux.org/CVE-2024-3094
[4] https://www.openwall.com/lists/oss-security/2024/03/29/4
Since you didn’t build a RPM or DEB package however, your didn’t compile in the backdoor.
Arch has pushed the patched xz just a few hours ago: https://archlinux.org/news/the-xz-package-has-been-backdoored/
Time to bring back the reproducible build hype
Won’t help here; this backdoor is entirely reproducible. That’s one of the scary parts.
The backdoor wasn’t in the source code, only in the distributed binary. So reproducible builds would have flagged the tar as not coming from what was in Git
Reproducible builds generally work from the published source tarballs, as those tend to be easier to mirror and archive than a Git repository is. The GPG-signed source tarball includes all of the code to build the exploit.
The Git repository does not include the code to build the backdoor (though it does include the actual backdoor itself, the binary “test file”, it’s simply disused).
Verifying that the tarball and Git repository match would be neat, but is not a focus of any existing reproducible build project that I know of. It probably should be, but quite a number of projects have legitimate differences in their tarballs, often pre-compiling things like autotools-based configure scripts and man pages so that you can have a relaxed ./configure && make && make install build without having to hunt down all of the necessary generators.
The back door is not in the source code though, so it’s not reproducible from source.
Why didn’t this become a thing? Surely in 2024, we should be able to build packages from source and sign releases with a private key.
