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 (…)
You must log in or register to comment.
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.
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?
Just to be sure, you should check whether SSHD is enabled:
sudo systemctl status sshd.serviceIf 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: xzChecked. We good. Thanks, stranger.
What if it was enabled but it was disabled in the firewall so it could only be used from the device itself?
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.
What if you had the service enabled on an Arch based distro?
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/
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…?
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.
Chances are very, very high, that you are not nearly interesting enough to warrant someone utilizing said back door to discover your stash of furry lewds. The primary target for an exploit like this, is either nation state level (industrial/political espionage, tampering with financial markets, etc.) or criminal enterprise level going after high value targets. Trying to dragnet every random whoever to see if they have data worth compromising wouldn’t be much of a money maker.
That said, this is one of the dangers of using a rolling release. I was running endeavourOS and was likely exposed to the back door for a while. I’ve since switched back to Fedora, which was only exposed on its testing branch (rawhide).
From my understanding, Arch based distros don’t link ssh with systemd, and so are likely unaffected. That includes EndeavourOS. Since researchers are still analyzing the code, Arch took some steps to patch it anyways, just in case there some other hidden backdoor.
Well that’s good to know. Still feeling pretty cozy on fedora, even got secure boot on for whatever that’s worth. Likely not much.
to discover your stash of furry lewds.
No need to call me out, even if my home instance makes that obvious.
Sorry I assumed you’d get a laugh out of it, wasn’t trying to do any harm.
I was being silly as well :P
lol. Okay good.
Maybe initially, when nobody knew about it. I bet it’ll be reverse engineered and filtered down to script kiddies soon, if it hasn’t already. If your server is affected, you should definitely fix it or even reinstall.
The backdoor’s probably not “installed” on anything but Debian & distros that use RPM so Arch would probably have been fine just due to that alone, see eg. this HN comment which summarizes things pretty well.
TL;DR don’t worry (for now) - it only impacts rpm and deb builds and impacted releases only really made it into OpenSuSe tumbleweed - if you’re running bleeding edge maybe you need to worry a little.
A laymans explanation about what happens is that the malicious package uses an indirect linkage (via systemd) to openssh and overrides a crypto function which either:
- allows access to the system to a particular key
- allows remote code execution with a particular key
Or both!
I have secondhand info that privately the reverse engineering is more advanced, but nobody wants to lead with bad info.
As for what you should do? Unless you’re running an rpm or deb based distro and you have version 5.6.0 or 5.6.1 of xz-utils installed, not much. If you are, well, that comes down to your threat model and paranoia level: either upgrade (downgrade) the package to a non-vulnerable version or dust off and nuke the site from orbit; it’s the only way to be sure.
Didn’t it also get into Debian testing and Sid?
Debian Sid would be considered “bleeding edge”, not sure about Testing. It also made it into Fedora’s Sid equivalent, Rawhide and the branch for Fedora 41 (due out in October)
TL;DR: Simply downgrade to a version before 5.6.0, or follow the official recommendations for your distro. For Arch, for example, simply upgrade your system.
Explanation (from my understanding ): a malicious developer snuck a backdoor into xz, starting with version 5.6.0,and thankfully it was caught before it could do much damage. This seems to only affect Fedora and Debian based distros, or otherwise distros where ssh is patched to link to systemd, which in turn links to xz. Arch doesn’t seem to be affected, but they took some preventative action. Again, follow the announcements from your distro, or just downgrade xz.
It is not yet clear what a malicious actor can do with that backdoor, but it seems, in affected systems, it enables remote code execution (if you don’t know what that means, just know it’s really bad), but last I checked security researchers were still analyzing the code. Things move fast, so maybe by now it is known.
Based on this very handy HN comment the long and short of it is that it would probably only have been a problem if you were running:
-
A very recent version of liblzma5 - 5.6.0 or 5.6.1. This was added in the last month or so. If you’re not on a rolling release distro, your version is probably older.
-
A debian or RPM based distro of Linux on x86_64. In an apparent attempt to make reverse engineering harder, it does not seem to apply when built outside of deb or rpm packaging. It is also specific to Linux.
-
Running OpenSSH sshd from systemd. OpenSSH as patched by some distros only pulls in libsystemd for logging functionality, which pulls in the compromised liblzma5.
So if all of those weren’t true for you, you’re most likely fine. Not a guarantee though since the backdoor’s still being analyzed and that comment is a couple of days old, but as far as I can tell it’s still reasonably accurate.
This doesn’t answer the question: what is the purpose behind adding the vulnerability? What specific things are vulnerable? What could it be used to do?
To allow somebody to change how the encryption between a server and client is handled so the communication can be intercepted. Either by putting a thumb on the scale for the cipher used or outright using a particular key that is known by an attacker.
E.g. to make a man in the middle or even passive traffic capture attack possible so they can choose to intercept supposedly secure traffic when they want to
I don’t know if the full extent of what it can be used for it known yet. Just that how they hook the calls for the traffic allows for some pretty nasty scenarios.
I literally just gave you a list of what’s vulnerable: Debian / RPM -based distros on x86_64 Linux that installed new versions of liblzma5 (which are so new that likely only rolling release distros had them), running OpenSSH sshd via systemd.
As to what it could be used to do and what its purpose is, well, the backdoor’s still being analyzed. Seems to be for remote code execution, ie. the attacker could theoretically execute code on a backdoored machine.
I’ve been wondering if there’s some kind of notification code that let’s the bad actor know they’ve successfully infected someone. Otherwise what’s the plan, trawl the entire IP space for devices your key can access? Wouldn’t it need UPNP or some other method to reach most people’s systems?
I think the intention probably wasn’t to get into Jane Q. Public’s home computer, but was aimed at being able to infiltrate more high value targets – corporations, governments etc. While I haven’t kept up with the latest findings in this, I’d guess the intention was to have the backdoor spread widely enough that you really wouldn’t need to scan for targets – Debian and distros that use RPM are very popular after all.
It’d definitely require the target to have their sshd open to the world, but that’s not uncommon at all unfortunately.
-
It would appear I explain things to five year olds very differently than people on Lemmy
I know you’re making a joke, but just in case you’re not, “ELI5” is about simplifying things for the layperson, not about actually explaining things to five year olds.
Listening to Клетка while reading about this situation feels so cyber-esque.
