Backdoor in upstream xz/liblzma leading to SSH server compromise

Original Article ↗ Hacker News Discussion ↗

A critical backdoor was found in recent releases of the widely used xz/liblzma compression library, enabling remote compromise of OpenSSH servers on certain Linux distributions by hijacking symbol resolution in libcrypto. Commenters examine how the attack was inserted only into release tarballs via opaque autotools build machinery and test “data” blobs, speculate it was a long‑term, likely state-backed supply-chain operation, and note that it was caught only because it caused performance regressions. The incident prompts broader concern about trust in maintainers, binary release artifacts, complex build systems, and the difficulty of auditing modern dependency chains, alongside practical notes on which distros and versions appear affected or safe.

Backdoor characteristics and behavior

  • Backdoor resides in xz/liblzma 5.6.0 and 5.6.1 release tarballs, not in the corresponding git tags.
  • Malicious code is injected via autotools machinery: an extra m4 script and obfuscated “test” binary data that get transformed into code during configure.
  • Payload patches liblzma’s initialization to hook the dynamic linker and redirect specific OpenSSL functions (notably RSA_public_decrypt) to attacker code.
  • Activation is heavily gated: x86‑64 Linux, gcc + GNU ld, built as part of .deb/.rpm packaging, ifunc enabled, and only when loaded into specific binaries (e.g. patched sshd). It also tries to evade sanitizers and interactive debugging.
  • Discovery came from sshd performance regressions and valgrind issues; several commenters note it could have gone unnoticed if more carefully tuned.

Who is affected (as discussed)

  • Affected space: x86‑64 Linux systems using xz/liblzma 5.6.0/5.6.1 built from the tainted tarballs, with OpenSSH linked (directly or via libsystemd/libselinux) to liblzma.
  • Debian: sid/testing briefly affected; stable uses 5.4.x and is reported as unaffected. A “5.6.1+really5.4.5” downgrade is used.
  • Fedora: rawhide / unreleased branches affected; RHEL releases use older xz and are reported unaffected.
  • Arch: briefly built from compromised tarball, then switched to building from git; sshd there does not link against liblzma.
  • NixOS and some non‑systemd distros appear largely unaffected due to different linking and packaging paths.
  • macOS and BSDs: discussion suggests they’re practically unaffected (wrong OS/ABI, older xz, different sshd linkage), though some urge caution until full analysis.

Maintainer, intent, and “state actor” debate

  • Commenters outline a multi‑year pattern: new contributor builds trust, becomes co‑maintainer, takes over releases and signing, adds complex ifunc and test infrastructure, then introduces the backdoor and pushes hard for rapid distro adoption.
  • Many speculate this is a long‑term, well‑funded operation, possibly by a state actor; others stress uncertainty and warn against mob justice or assuming motives without proof.
  • Some point out alternative scenarios: account takeover, coercion, or multiple coordinated personas (e.g. “burner” contributors and pressure campaigns on distros).

Build systems, tarballs, and supply‑chain lessons

  • Strong criticism of autotools “soup” and generated scripts in release tarballs: they are huge, opaque, and diverge from VCS, making them ideal for hiding malware.
  • Several argue distros should:
    • Refuse upstream-generated configure scripts and always regenerate from source (autoreconf), or
    • Treat any file present in a tarball but not in git as suspect.
  • Others generalize: build systems (autoconf, CMake, Rust build.rs, etc.) all allow arbitrary code execution at build time; complex tooling and binary testdata massively expand the attack surface.
  • Reproducible builds are praised but seen as insufficient if the “source” being built already contains hidden generators.

Systemd, dependency bloat, and exposure

  • A major thread blames distro patches that link sshd against libsystemd solely for sd_notify support, which in turn pulls in liblzma and widened the attack surface.
  • Others counter:
    • The sd_notify protocol is trivial; projects can and do implement it directly without libsystemd.
    • libselinux also drags in liblzma for many daemons; even without systemd, similar paths exist.
  • Broader systemd debate erupts: some see its size and reach as an auditing nightmare; others argue it centralizes and standardizes service management that previously lived in fragile ad‑hoc scripts.

Mitigations and broader security themes

  • Immediate mitigations discussed:
    • Downgrade xz/liblzma to pre‑5.6 versions.
    • Run signature‑based detectors looking for the specific malicious byte sequence in liblzma.
    • Rebuild from clean git tags, regenerating build artifacts, and strip suspicious test binaries.
  • Longer‑term ideas:
    • Audit or roll back all commits and tarballs signed by the implicated maintainer(s); some suggest treating everything from certain versions onward as untrusted until proven otherwise.
    • Reduce binary blobs and generated files in source distributions; keep tarballs as close as possible to the VCS tree.
    • Invest in sandboxing and capability‑based security so that even compromised libraries have limited ability to interfere with unrelated components.
  • Several participants note this likely isn’t a unique incident, only a rare one that was caught due to a performance regression, and call for more realistic assumptions about the security of widely‑used open‑source dependencies.