Vulnerability in upstream XZ and liblzma libraries causing SSH server exposure
Vulnerability in upstream XZ and liblzma libraries causing SSH server exposure
Arch has released it to mainline for a month now. I know cause I used CachyOS. There is not but Linux is unreliable on the current state of things. I don't want to be unsure about the security of the OS I'm using. Thank God no. Could you elaborate? How come? The potential implications of this are immense. I will switch back once all this is resolved. Until then, Windows is the best option since this is a very serious issue.
Consensus reached, developers don't test cutting-edge features on stable platforms for their releases. It's a way for issues to surface naturally. I question whether Fedora teams operated on their own unstable environments, but when building for other systems, they prioritize the most reliable and mature OS available. No one seeks flawed binaries or archives. The latest upload was just five weeks ago, so anything released before February 23rd has no real risk of compromise. If you're worried about exposed services like sshd on a public IP with RSA keys and systemd, check the process list with ldd and ensure liblzma is present.
And as mentioned before in this discussion, Arch remains safe. I actually run arch and it doesn’t matter much. Plus, unless your machine’s SSH port is publicly reachable, there’s really little cause for concern. Oh no worries, if you’re short on time: here are some useful links https://www.ncsc.gov.uk/information/log4...ds-to-know and https://www.trendmicro.com/en_us/what-is...ility.html. If you’re concerned about potential effects, it’s safer to avoid using any device altogether. OpenSSH, the system targeted here, has known issues periodically: https://www.openssh.com/security.html and a recent blog post about remote code execution in forwarded SSH agents: https://blog.qualys.com/vulnerabilities-...-ssh-agent. In short, vulnerabilities are part of software—patch them and proceed. The biggest issue here is intentional exploitation, making it a supply chain threat. You’re likely using many applications with open CVEs, and Windows environments probably face even more problems.
In recent months, a complex, multi-phase harmful script was secretly inserted into versions 5.6.0 and 5.6.1 of xz/liblzma, a popular Unix compression tool. This change was introduced by one of the project’s open-source contributors [4]. Prior to its exposure around March 29, 2024, the backdoor was installed on Fedora Rawhide (now Fedora 41 preview/beta) users and also appeared in Debian testing, unstable, and experimental releases [2] and Red Hat Enterprise Linux distributions [5]. As a precaution, immediate updates are advised for Fedora Linux 40 [2] and Arch Linux [6], though Arch users likely received the compromised package without active malware for about two weeks. Debian stable and its derivatives (such as Ubuntu) and Red Hat Enterprise Linux remain assumed safe since they haven’t updated to the affected xz version. Internally, Red Hat rated the related vulnerability CVE-2024-3094 at a severe 10/10 [3]. The threat was uncovered due to performance and stability problems linked to its later phase, which interacted with openssh/sshd—the most common remote login tool on Linux. Ongoing analysis suggests it could enable unauthorized remote SSH access. [4] My perspective views this as the most severe supply chain compromise in open-source history. If the backdoor had remained undetected and been deployed to millions of Debian and Red Hat servers, the consequences would have been catastrophic. The perpetrators are likely state-sponsored hackers who invested significant time in legitimate development to conceal their actions. Sources [1] https://www.phoronix.com/news/XZ-CVE-2024-3094 [2] https://www.redhat.com/en/blog/urgent-se...hide-users [3] https://access.redhat.com/security/cve/CVE-2024-3094 [4] https://www.openwall.com/lists/oss-secur...24/03/29/4 [5] https://lists.debian.org/debian-security...00057.html [6] https://archlinux.org/news/the-xz-packag...ackdoored/
This changes the meaning completely. It’s more about avoiding issues than adding them.
it's not unusual, it's merely a subtle irony that someone from Microsoft stumbled upon a backdoor while working on something completely different. Unlike the developers of the affected distribution, who are likely more attuned to security issues, this oversight highlights how even minor details can be exploited. After considering it, it seems the exploit's simplicity might actually be its vulnerability—by focusing on SSH logins, anyone testing performance could have easily noticed the issue. beyond this, it underscores the harsh truth about complex ecosystems like Arch Linux, which lack effective safeguards against such threats.
I disagree, packages go through validation and testing before they're thrown into the repos and this didn't just randomly occur because of a single malicious commit by a random contributor. Clearly there was long standing malicious intent behind this and collaboration from the upstream developers; hypothetically this could have been done with a "bugfix" of an older release, which could have made its way into any distribution. Moreover Arch was not affected , so it's possible that if the backdoor had been active in the Arch build it would have been caught by the Arch maintainers - we just can't know for sure. Debian Sid and Fedora Rawhide are considered testing distributions so they don't have the same safeguards as mainline Arch - if you want that experience on Arch you need to look at the testing repo.
I believe this video provides a clear and comprehensive explanation.
The key aspects often overlooked involve how configuration decisions and system configurations must align for malicious code to function. Here’s a summary:
- An SSH daemon operating on an open port assigned to a public IP address
- Using RSA private/public key authentication with systemd
- Systemd built with lzma support
- OpenSSH has been updated to connect sshd with libsystemd
- A compromised liblzma component is present
- Two groups exist: those aware of the risks and prepared to act, and those who accept consequences
- Most users follow standard SSH setup guides without issue
- The approach is typical for beginners learning how to configure SSH servers
- This situation is rare and usually involves advanced or experimental setups
- It carries real implications for future operations, not because most servers are inherently compromised
- The concern stems from potential security exposure, not widespread infection rates