Backdoor in upstream xz/liblzma leading to SSH server compromise

Original Article ↗ Hacker News Discussion ↗

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.