_
[WHO AM I]
SYSTEM: ONLINE
Back to Dashboard

XZ Utils Supply Chain Compromise (CVE-2024-3094)

SEV: HIGH
March 2024
STATUS: RESOLVED
ID: LOG-0102

Incident Report

The "Long Con" Supply Chain Attack

In March 2024, the open-source ecosystem narrowly avoided one of the most significant security breaches in history. A malicious actor known as "Jia Tan" (JiaT75) spent nearly two years building trust within the XZ Utils project before injecting a backdoor into the liblzma compression library (versions 5.6.0 and 5.6.1).

[Image of software supply chain attack diagram]

Unlike typical vulnerabilities, this was not a coding mistake. It was a deliberate, obfuscated injection designed to grant unauthorized Remote Code Execution (RCE) on Linux servers via SSH.


Technical Breakdown: How it Worked

The genius of this attack lay in its concealment. The malicious code did not exist in the public GitHub source code. Instead, it was injected only into the release tarballs (the compressed source files used by Linux distributions to build packages).

1. The Build System Injection

The attacker modified the m4 build scripts (specifically build-to-host.m4) included in the tarball. During the ./configure and make process, this script:

  1. Extracted a hidden object file from what appeared to be "corrupt" test files in the tests/ directory.
  2. Modified the Makefile to link this malicious object into liblzma.

2. The Linkage Chain

Why does sshd (SSH Daemon) load a compression library?

  • sshd is often patched to support systemd-notify for service management.
  • libsystemd depends on liblzma for compressing journal logs.
  • Therefore: sshd -> libsystemd -> liblzma (Infected).

You can verify this dependency chain on a Linux system using ldd and tree:

# Checking the dependency chain ldd /usr/sbin/sshd | grep libsystemd # Output: libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 ldd /lib/x86_64-linux-gnu/libsystemd.so.0 | grep liblzma # Output: liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5

3. IFUNC Hooking

The backdoor utilized the glibc IFUNC (Indirect Function) mechanism. IFUNC allows a program to select the best implementation of a function at runtime (e.g., optimized for AVX-512).

The malicious code hijacked this resolver to replace the RSA_public_decrypt function pointer with its own code. During an SSH handshake:

  • It checks the connecting user's public key.
  • If the key matches the attacker's private key, the payload executes commands as root.
  • If not, it passes execution back to the real RSA_public_decrypt, making the backdoor invisible to normal users.

The Discovery: A 500ms Anomaly

The backdoor was discovered by Andres Freund, a Microsoft PostgreSQL developer. While benchmarking Postgres on Debian Sid, he noticed sshd was consuming unusually high CPU and saw a roughly 500ms latency increase during logins.

"I am not a security researcher, but I noticed sshd taking a lot of CPU... valgrind showed a lot of errors in liblzma."

Using perf and valgrind, he traced the latency to the compromised symbols in liblzma, preventing the backdoor from reaching stable Linux distributions (like Debian Stable, RHEL, or Ubuntu LTS).

Mitigation

Immediate action required downgrading XZ Utils to version 5.4.x or earlier.

# Check your version xz --version # If output is 5.6.0 or 5.6.1, update immediately.

This incident has sparked a major industry debate on how to support burnout-prone open-source maintainers and verify the integrity of binary artifacts (using tools like Sigstore).

SYSTEM NOTES

This log entry has been verified and archived. Access restricted to authorized personnel only.