GitHub Repository xz (Suspended)
Source Code https://git.tukaani.org/?p=xz.git
Threat Actor Jia Tan (GitHub)
CVE Number CVE-2024-3094 (CVSS 10.0)
Vulnerability Type Remote Code Execution
Attack Category Social Engineering, Supply Chain Attack

What does xz module do?

XZ Utils is a set of free and open-source data compression utilities that provide high compression ratios and fast decompression. It primarily uses the LZMA compression algorithm, which is an algorithm for lossless data compression.

Here are some common uses of XZ Utils:

  1. File Compression: Shrinks files and directories into .xz format, ideal for software distributions, backups, and archives.
  2. Packaging Software: Linux distros utilize XZ Utils to compress software packages, reducing bandwidth and storage requirements.
  3. Archiving: Creates compressed archives akin to tar or zip, simplifying storage and distribution of multiple files or directories.
  4. Backup Compression: Efficiently compresses backup files, particularly beneficial for large backups with limited storage space.
  5. Embedded Systems: Valued in embedded systems for its compactness and swift compression/decompression.
  6. Software Distribution: Developers streamline software distributions with XZ Utils, enhancing download speeds and reducing bandwidth usage.

Where it is being used?

xz module was used in different operating systems, a detailed list of the operating system using this module can be found on Repology/xz.

Version of xz in different OS

Version of xz in different OS

and if you dive deeper in each operating system there are multiple dependencies on this module, For example Arch(core) has around 151 dependencies on this specific module -

Dependency of xz on Arch Modules (https://archlinux.org/packages/core/x86_64/xz/)

Dependency of xz on Arch Modules (https://archlinux.org/packages/core/x86_64/xz/)

Here the SBOMs are going to be helpful in understanding where the modules are being used and at what level the issue is propogated.

Brief about the vulnerability

Andres Freund while performing micro-benching activity observed that sshd was consuming a large amount of CPU and taking more than usual time during login process. He also encountered numerous errors when using Valgrind tool for profiling and memory debugging and then he emailed oss-security about the backdoor in the xz module.

xz meme

On March 29th, reports surfaced of malicious code discovered within XZ Utils, a widely-used package in major Linux distributions. This code enabled unauthorized SSH access. Detected in versions 5.6.0 and 5.6.1 released within the past month, the attack targeted OpenSSH servers. Remote attackers with a specific private key could execute arbitrary payloads through SSH, hijacking victim machines. Despite XZ Utils' trusted status, the attacker, posing as an OSS developer, evaded detection using highly obfuscated code.

Attack Timelines & Technical Details

Initially, the vulnerability appeared to be an authentication bypass, but after further analysis by the researchers , it was determined to be a remote code execution (RCE) issue.

In brief, it was a sneaky backdoor in the test files, the backdoor was not directly inserted into the source code of liblzma that is visible in version control systems or utilized by xz directly. Instead, it was hidden within binary test files in the xz compressed format. These files appeared benign and were theoretically part of the library’s test suite. A sophisticated method was employed where the backdoor was split into parts and concealed within two xz compressed files. These files were disguised as ordinary test files, evading detection from casual inspection or automated tools that scan for malicious patterns.

The diagram by Wiz, gives a good eagle eye view on what happened and how a threat actor can use it to compromise victim’s systems - Diagram

Detection & Defence

JFrog Research Team released an OSS tool to detect this vulnerability - cve-2024-3094-detector.sh

If you have some kind of CSPM in your organziation, they should also give you a comprehensive view of how your environment is affected.

As a product security person, you can estimate the risk by using different tools to create SBOMs, and consider other parameters that affects the expoitability and work towards downgrading the module and limiting the attack surface.

As a potential workaround for affected systems, where upgrading is not possible, consider adding the following line to /etc/environment:

echo "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" | sudo tee -a /etc/environment

Afterward, ensure to restart both the SSH and systemd services. ( ref. - backdoor's kill switch )

The main defense to this right now, can be downgrading the version of xz to such as XZ Utils 5.4.6 Stable. ( ref. )

The presence of extensive code, much of which may not even be under your control or managed by a third party, poses a significant challenge in defending against this type of attack. Unfortunately, in such cases, there isn’t much that can be done to effectively defend oneself. This attack could potentially affect anyone, as the actions taken were not overtly suspicious. So 😔 Yeah!

Some Other Bits

In the above sections, I have mentioned that SBOMs are going to be helpful in understanding the attack surface, but SBOMs alone cannot guarantee the exploitability of the vulnerability.

There are other factors in play, there are some pre-requisites that comes in the picture -

  • The OS must be x86-64 Linux. (because of this Homebrew is not affected but worth upgrading downgrading the version.)
  • The xz build process must be part of a Debian or RPM package build. This makes it more difficult to reproduce, as the backdoor won’t be installed when attempting to manually build the xz package.

If you are using a distroless image for hosting, chances are you are safe, but still downgrading the version is a good to perform task.

The term “SSH backdoor” is misleading in this context. OpenSSH doesn’t directly use xz, but Linux distribution maintainers linked xz into sshd during building, possibly for better integration with systemd. xz is so widely linked into packages that it’s challenging to determine the full scope of the potential impact of the backdoor.

There have been discussions regarding the mental health of the project maintainer, with perspectives on both sides of the issue. While I lean towards the viewpoint that security shouldn’t be linked to the maintainers' mental health. I would give you instance of both types of conversations -

The attacker also takes extra steps to get more involved in the OSS community and gain trust, hence there are other softwares where he contributed to -

Another fun instance is when the attacker themselves help fix the issue in valgrind, that was caused because of their backdoor 🤣 ( ref. )

Looking at all these things, it looks like the efforts put in to perform this level of supply chain attack, might be some state sponsored act and it also sparks a discussion on open source security and contributions and doing it keeping sanity in mind.

More Reading?

There are more scenarios that are popping up on the extent this can be exploited and there are so many open questions out there. More information is going to be added in the blog as when things emerges.

Until then, Ciao!

P.S. - Thanks @anantshri for your inputs & review!