On Friday, March 29, a Microsoft developer revealed a major vulnerability impacting XZ Utils, a popular collection of lossless data compression tools and libraries.

The vulnerability was later confirmed by Red Hat and assigned CVE-2024-3094. It was given a CVSS severity score of 10.0, the highest possible. 

CVE-2024-3094 is considered such a serious threat because it allows for potential remote code execution, giving attackers the ability to run malicious software, access sensitive data, or gain control over the affected systems from anywhere in the world. 

If there is a piece of good news related to the exploit, it’s that the vulnerability was likely caught before doing widespread harm. Although XZ Utils is used across the Linux world, the vulnerability impacts only XZ Utils versions 5.6.0 and 5.6.1. And, as of this writing, CVE-2024-3094 is only confirmed to impact Fedora Rawhide, Fedora Linux 40, Debian (testing, unstable, and experimental distributions, versions ranging from 5.5.1alpha-0.1 up to and including 5.6.1-1), Arch Linux, Kali Linux, openSUSE Tumbleweed, and openSUSE MicroOS. 

The recommended mitigation is to immediately downgrade to a safe version, such as 5.4.6 Stable. Additionally, since vulnerable versions of XZ Utils have been distributed in the Linux ecosystems mentioned above, you should follow the applicable vendor guidance for reverting and/or upgrading Linux distributions.

In this blog, we’ll discuss the nature of the XZ Utils vulnerability, the unusual way it was discovered, and best practices for remediating the issue.

RELATED: FOSSA Package Index for Zero-Day Vulnerability Management

CVE-2024-3094 Background and Discovery

News of the XZ Utils vulnerability first came to light in an Openwall thread from Microsoft developer Andres Freund. 

Freund posted that he observed degraded performance related to part of Debian sid installations. Specifically, SSH logins a) consumed more CPU than expected, and b) caused valgrind errors. 

These issues led Freund to investigate. At first, he thought Debian’s package may have been compromised. However, further exploration led Frend to conclude that the issue was actually with the upstream XZ repo and tarballs.

It also soon became clear that CVE-2024-3094 was no ordinary software supply chain attack. Rather, it was the result of a sophisticated, multi-year process that culminated in a bad actor — perhaps/probably a state-sponsored one — becoming a trusted contributor to XZ Utils and inserting a backdoor.

In November 2021, GitHub user Jia Tan (“JiaT75”) made what appears to be their first commit to an open source project. In 2022, Tan submitted a patch to the XZ Utils mailing list; several sockpuppet accounts responded to Tan’s submission pressuring the original XZ Utils project maintainer to add co-maintainers. (The intent of these efforts was seemingly to convince the original maintainer to add Tan to the project.) 

In the months that followed, Tan continued to contribute to XZ Utils, gaining trust and stature. This ultimately resulted in Tan being able to create and release compromised tarballs in XZ Utils 5.6.0 and 5.6.1.

How the XZ Utils Vulnerability Works

The XZ Utils vulnerability introduces a backdoor that allows an attacker to send hidden commands via sshd when establishing an SSH connection. By providing a specific private key (known only to the attacker), arbitrary commands can be sent to the affected system prior to the authentication step, enabling unauthenticated remote code execution.

Here’s a summary of requirements to be affected by the malicious code:

  1. Using a .deb or .rpm based distro that uses glibc
    a. amd64/x86_64 based architecture
  2. 5.6.0 or 5.6.1 of xz or liblzma installed
  3. Publicly accessible sshd (although privately accessible may be vulnerable)

Here’s a summary of how the attack works on an affected system:

  1. Backdoor Establishment: The backdoor is put in place, having been intricately compiled from various test files, which were disguised as legitimate inputs and embedded within the build process through a complex scheme of scripts and modified configuration files. This setup ensures the backdoor is activated, listening for incoming SSH connections.

  2. Authentication Process: When a client tries to authenticate, it sends its public key to the server as part of the standard SSH handshake, initiating the authentication dialogue.

  3. Interception by Malicious Code: At this juncture, the maliciously inserted code that has taken over the RSA_public_decrypt function springs into action. This function, meant for validating RSA signatures, is now repurposed to analyze the data received during the handshake.

  4. Revealing Hidden Commands: The tampered function decrypts certain parts of the incoming authentication data, unveiling hidden instructions that were embedded within what is typically a secure RSA signature process.

  5. Signature Authentication: The decrypted data is subjected to a verification process to authenticate its origin. This step ensures that only instructions from the attackers, who have the required private key, are accepted and processed further.

  6. Command Execution: Upon successful verification indicating that the instructions originate from the attackers, these instructions are executed on the server. This critical step allows the attackers to perform unauthorized actions on the system without completing the standard authentication protocol.

  7. Seamless Fallback: If the incoming data does not conform to the attackers' specifications or fails the verification stage, the backdoor reverts to the legitimate functionality of the RSA_public_decrypt function. This behavior ensures the backdoor remains hidden during regular SSH operations, maintaining the appearance of normalcy.

Finding and Fixing the XZ Utils Vulnerability

As discussed, thanks to Andres Freund’s timely discovery, the XZ Utils vulnerability appears to impact only a handful of distributions. It’s highly recommended to a) downgrade to a safe version of XZ Utils, and/or b) follow vendor guidance for mitigating the vulnerability in:

FOSSA customers can quickly verify whether they are using the vulnerable packages anywhere in their organization by navigating to Package Index and searching for CVE-2024-3094. Any impacted packages, projects, and teams will be returned in the search results.