Be on high alert, because Red Hat has issued a stern warning concerning a discovered backdoor in XZ tools, which are frequently used by most Linux distros. The highly unsettling situation came to light when users were told to immediately halt the use of systems operating Fedora development and experimental versions, due to the backdoor identified in the recent XZ Utils data compression tools and libraries. This alert isn’t one to disregard as Red Hat and Debian’s security teams have confirmed that successful injections have evidently been built in xz 5.6.x versions specifically produced for Debian unstable (Sid). Even though no stable Debian versions or versions of Red Hat Enterprise Linux (RHEL) are adversely affected, other distribution versions might be. Crisis management steps have been promptly taken by Kali Linux, openSUSE, and Arch Linux as they’ve published their own security advisories as well, reversing versions in the affected releases.
Introduction
Welcome! Today we are delving into a significant issue that occurred recently in the Linux world that has caused quite a stir – a backdoor was found in XZ tools. XZ tools are commonly used across numerous popular Linux distributions, and its discovered vulnerability has resulted in immediate action.
Red Hat’s Warning
XZ Tools Used by Linux Distros
Firstly, let’s take a moment to understand what these XZ tools are. In essence, they are data compression tools and libraries widely utilized by several Linux distributions. This makes them an integral part of many systems operating on Linux.
Backdoor Discovered
It was recently brought to light that a backdoor was discovered in the most recent versions of XZ tools. As concerning as it sounds, this essentially means that there was a hidden vulnerability in the XZ tools that could potentially allow unauthorized access to the system where they were installed.
Immediate Action Required
Upon discovering this backdoor, Red Hat issued a stern warning to the users, urging them to immediately stop using systems running Fedora development and experimental versions. The seriousness of the situation is quite evident from the urgency in Red Hat’s announcement.
Affected Distributions
Since XZ tools are widespread across different Linux distributions, finding out which distributions are affected was crucial. Red Hat luckily found that its Enterprise Linux versions remained unaffected. However, other distributions that were impacted include Fedora, Debian, Kali Linux, openSUSE, and Arch Linux.
Fedora
Interestingly, Fedora was noted as one of the most directly impacted by this backdoor. Consequently, Red Hat made an assertive recommendation to discontinue its use in both Fedora 41 and Fedora Rawhide instances.
Debian
Though all stable versions of Debian were deemed safe, other iterations of Debian like testing, unstable and experimental distributions needed to revert their XZ to the upstream 5.4.5 code to mitigate the risks.
Kali Linux, openSUSE, and Arch Linux
Similar to Debian, Kali Linux, openSUSE, and Arch Linux also had to take immediate measure by posting security advisories and reversing their XZ versions in the affected rolling releases.
Checking for the Compromised Version
Determining whether your system might have a compromised XZ version is the first step you should take in light of this warning. To do this, you need to query the package manager or run a specific shell script. If your version is 5.6.0 or 5.6.1, then immediate action is advised.
Using Package Manager
Your trusty package manager can be the quickest way to check the XZ version installed on your system. A simple query can determine if your version could be the compromised one.
Running Shell Script
Alternatively, a shell script uploaded by a cybersecurity researcher can also help identify the version of XZ you have installed. This script finds all instances of the XZ executable and outprints its embedded version, providing a reliable way to spot the issue without running the compromised program itself.
Downgrading to Older Versions
If it turns out you are using a compromised version, the immediate solution is to downgrade to an older version that doesn’t contain the malicious code. The affected 5.6.x versions need to be reverted to safer older versions to eliminate the backdoor.
Discovery of the Security Issue
So, how was this security issue initially discovered? A Microsoft software engineer named Andres Freund came across the vulnerability while troubleshooting slow SSH logins on a Linux box running Debian Sid.
Investigating Slow SSH Logins
Andres Freund started noticing that his SSH logins were unusually slow. This aroused suspicion, and upon inspecting, he discovered evidence of the injected code in the affected XZ versions.
Contributor and Malicious Code
The coder who allegedly added the malicious code was a contributor named Jia Tan. The rogue code was hidden in the liblzma data compression library of XZ versions 5.6.0 and 5.6.1.
Unauthorized Access and Remote Code Execution
Freund concluded that the malicious code likely allowed some form of unauthorized access or remote code execution. While he could not precisely understand the purpose of the injected code, the fact remained that it posed a genuine threat to the security of the affected systems.
Revert to Secure Versions
The suggestion was to revert to 5.4.x versions in Fedora Beta to avoid the compromised XZ versions. The severity of the situation was underscored by the critical scoring given to the issue, logged as CVE-2024-3094.
CVE-2024-3094
Red Hat began tracking this as the security issue CVE-2024-3094, assigning it a maximum 10/10 severity score, indicative of a major threat to the affected systems.
Reverting to 5.4.X Versions
Users were therefore advised to immediately revert XZ to 5.4.x versions, none of which contained any malicious code, to ensure the safety of the Linux distributions like Fedora 40 beta.
Obfuscated Malicious Code
The malicious code was notably obfuscated to evade detection. It was injected into the complete download package, rendering it invisible to the Git distribution, which lacked the triggering component for the backdoor build process.
Git Distribution
The malicious macro responsible for activating the backdoor build wasn’t present in the Git distribution, thus avoiding detection. However, if it was present at any time, it had the capacity to activate the second-stage artifacts embedded in the Git repository during the build time.
CISA Advisory
In addition to Red Hat’s warning, CISA (the Cybersecurity and Infrastructure Security Agency) also issued an advisory, urging users to downgrade to an uncompromised version. This meant downgrading to 5.4.6 Stable, followed by close monitoring for any suspicious activity on their systems.
Downgrade to Uncompromised Version
CISA’s advisory stressed the importance of immediately downgrading to an uncompromised version to prevent any potential breaches.
Hunting for Suspicious Activity
CISA further advised users to be vigilant and hunt for any suspicious activity in their systems, adding an extra layer of safety in the wake of the discovery of this backdoor.
Practical Impact
While the news broke with alarming headlines, the practical impact can be considered limited to a few “rolling distros” and testing facilities that import the newest upstream code. As such, the majority of distributions didn’t come into contact with the compromised versions. Even the backdoor itself required very specific environments to trigger, further limiting its potential damage.
Misleading Headlines
Although initial headlines suggested that most Linux distributions were compromised, this was not the case. The backdoor was only imported to a few specific “rolling distros”, with the majority of distributions unaffected.
Limited Impact on Majority of Distributions
Many distributions were unaffected, as they typically use much older versions of XZ tools. This incident, therefore, highlights the importance of careful scrutiny of astral releases to prevent potential vulnerabilities.
Conclusion
The incident brings to light how even ubiquitous and trusted tools like XZ may harbor security threats. It underlines the need for vigilance and prompt responses to address potential vulnerabilities. While the sheer scale of panic the discovery induced seemed excessive, considering the practical impact, it served as an essential wake-up call for all involved in the open-source community.