Today, Red Hat warned users to immediately stop using systems running Fedora development and experimental versions because of a backdoor found in the latest XZ Utils data compression tools and libraries.
"PLEASE IMMEDIATELY STOP USAGE OF ANY FEDORA 41 OR FEDORA RAWHIDE INSTANCES for work or personal activity," Red Hat warned on Friday.
"No versions of Red Hat Enterprise Linux (RHEL) are affected. We have reports and evidence of the injections successfully building in xz 5.6.x versions built for Debian unstable (Sid). Other distributions may also be affected."
Debian's security team also issued an advisory warning users about the issue. The advisory says that no stable Debian versions are using the compromised packages and that XZ has been reverted to the upstream 5.4.5 code on affected Debian testing, unstable, and experimental distributions.
Kali Linux, openSUSE, and Arch Linux have also published security advisories and reversed versions in affected rolling releases.
Linux admins can check which version of XZ is installed by querying with their package manager or by running the following shell script shared by cybersecurity researcher Kostas.
for xz_p in $(type -a xz | awk '{print $NF}' | uniq); do strings "$xz_p" | grep "xz (XZ Utils)" || echo "No match found for $xz_p"; done
The above script will perform the 'strings' command on all instances of the xz executable and output its embedded version. Using this command allows you to determine the version without running the backdoored executable.
If you are using versions 5.6.0 or 5.6.1, you are advised to immediately downgrade to older versions that do not contain the malicious code.
Microsoft software engineer Andres Freund discovered the security issue while investigating slow SSH logins on a Linux box running Debian Sid (the rolling development version of the Debian distro).
However, he has not found the exact purpose of the malicious code added to the liblzma data compression library in XZ versions 5.6.0 and 5.6.1 by contributor Jia Tan (JiaT75).
"I have not yet analyzed precisely what is being checked for in the injected code, to allow unauthorized access. Since this is running in a pre-authentication context, it seems likely to allow some form of access or other form of remote code execution," Freund said.
"Initially starting sshd outside of systemd did not show the slowdown, despite the backdoor briefly getting invoked. This appears to be part of some countermeasures to make analysis harder."
Red Hat reverts to XZ 5.4.x in Fedora Beta
Red Hat is now tracking this supply chain security issue as CVE-2024-3094, assigned it a 10/10 critical severity score, and reverted to 5.4.x versions of XZ in Fedora 40 beta.
The malicious code is obfuscated and can only be found in the complete download package, not in the Git distribution, which lacks the M4 macro, which triggers the backdoor build process.
If the malicious macro is present, the second-stage artifacts found in the Git repository are injected during the build time.
"The resulting malicious build interferes with authentication in sshd via systemd. SSH is a commonly used protocol for connecting remotely to systems, and sshd is the service that allows access," Red Hat said.
"Under the right circumstances this interference could potentially enable a malicious actor to break sshd authentication and gain unauthorized access to the entire system remotely."
CISA also published an advisory today warning developers and users to downgrade to an uncompromised XZ version (i.e., 5.4.6 Stable) and to hunt for any malicious or suspicious activity on their systems.
Update April 01, 12:40 EST: Added info on other affected Linux distros.
Comments
h_b_s - 4 weeks ago
Headline "Red Hat warns of backdoor in XZ tools used by most Linux distros" is misleading to the point of being incorrect.
Yes xz is a compression utility used in many, if not most, Linux distributions. However, the compromised versions of xz was only imported into a few "rolling distros" and testing facilities that tend to import the newest upstream code for testing. It never did make it to the majority of distributions as they are locked on much older xz releases. The last information I have, the backdoor is at best buggy and only triggers when certain environments are encountered in a complicated chain of dependencies that requires 3rd party pactches, NOT in generic Unix-like environments. EG: macOS, *BSD, etc wouldn't be affected with the current understanding because none of them use SystemD let alone the environment patches necessary to fully trigger the backdoor. There are even some Linux distributions that wouldn't trigger the backdoor at all because they don't use the patch chains even if they have SystemD. This is not much-ado-about-nothing as it should be a wake up that open source isn't invulnerable to supply chain compromise like what happened here (apparently intentional long-term compromise of a project), but the level of hysterics and over-the-top headlines like the one above are just plain incorrect about the practical impact.
Mahhn - 3 weeks ago
h_b_s Thanks for sharing the granular info. good stuff