84
ELI5: The Linux xz backdoor situation
(pawb.social)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 31 Mar 2024
84 points (95.7% liked)
Explain Like I'm Five
14261 readers
49 users here now
Simplifying Complexity, One Answer at a Time!
Rules
- Be respectful and inclusive.
- No harassment, hate speech, or trolling.
- Engage in constructive discussions.
- Share relevant content.
- Follow guidelines and moderators' instructions.
- Use appropriate language and tone.
- Report violations.
- Foster a continuous learning environment.
founded 1 year ago
MODERATORS
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/
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:Checked. 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/
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.