XZ backdoor: "It's RCE, not auth bypass, and gated/unreplayable."

Original Article ↗ Hacker News Discussion ↗

Nature of the backdoor / exploit

  • Backdoor lives in xz / liblzma and, via dynamic linking chains (e.g., libsystemd, libselinux), can end up inside sshd.
  • It hooks OpenSSL’s RSA signature verification (e.g., RSA_public_decrypt) and inspects the RSA n field.
  • If the data decrypts correctly (ChaCha20) and verifies against an embedded Ed448 public key, the decrypted payload is passed to system(), giving remote code execution in the sshd process context, typically as root.
  • If decryption/signature fail, it falls back to normal behavior, making it hard to distinguish from a normal failed login.
  • Because the trigger is gated by a private key only the attacker holds, it’s a NOBUS‑style backdoor: others can’t practically reuse or scan with it (“unreplayable”).

Scope, impact, and detection

  • Current analyses say the working exploit path is through OpenSSH pre‑auth; no confirmed path yet outside OpenSSH, but that’s still being investigated.
  • Only specific xz versions (5.6.0/5.6.1 in certain rolling/testing distros) carried the payload; most stable releases (Debian stable, RHEL, Ubuntu LTS, etc.) never shipped it.
  • Discovery came from a noticeable sshd slowdown and CPU spikes, not traditional security tooling.
  • Remote scanning is effectively impossible without the attacker’s key; detection is mainly via local version checks and behavioral analysis.
  • Some suggest potential timing or handshake‑phase analysis, but others note high noise and only probabilistic value.

Sandboxing, SELinux, and sshd

  • Extensive debate on whether SELinux, seccomp, or OpenBSD‑style pledge/unveil could have substantially limited damage.
  • Consensus trend:
    • Sandboxing can restrict root’s ability to alter core system state, but sshd’s purpose (spawning user shells) makes strong containment hard in general-use systems.
    • SELinux domains can significantly constrain even root processes and their children, but policies must be carefully crafted and are often disabled in practice.
    • For special-purpose sshd (e.g., git‑over‑ssh, jump hosts), sandboxing is far more realistic and useful.

Supply-chain mechanics and obfuscation

  • Backdoor was introduced over years via:
    • Gaining trust and de facto maintainership of xz.
    • Binary “test data” blobs that actually contained an 80+ KB payload.
    • Build‑system tricks to compile and inject that payload only for release tarballs / certain build modes (e.g., distro packaging).
    • A one‑character syntax error (“sneaky dot”) in a CMake feature test to permanently disable sandboxing support for xzdec in CMake builds.
    • Social engineering to tone down or disable fuzzing that might have noticed discrepancies.
  • The code detects debuggers, certain environments (TERM/LANG/LD_*), and only fully engages under very specific conditions (e.g., systemd‑style sshd startup), complicating reverse engineering.

Attribution, intent, and law enforcement

  • Many commenters see the operation’s patience, obfuscation, and NOBUS keying as indicative of a state actor or state‑scale sophistication; others note capable criminal groups could also do this.
  • Jurisdiction and concrete offenses are debated:
    • Some argue CFAA‑style laws and similar (or UK’s Computer Misuse Act) clearly cover intentionally shipping a backdoored library that causes damage.
    • Others note no confirmed exploitation yet, and that “malicious code” vs “vulnerable code” lines can be legally fuzzy.
  • Some warn that governments themselves may be responsible or will at least hoard similar 0‑days, reducing incentive to disclose.

Security posture, dependencies, and ecosystem lessons

  • Strong criticism of:
    • Dynamic linking into critical daemons (e.g., sshd) for non‑essential features (systemd readiness, PAM, SELinux tooling), inflating attack surface.
    • Complex, opaque build systems (autotools/cmake) and runtime features like IFUNC that make code harder to audit.
  • Disagreement on whether dynamic linking is fundamentally a mistake; some argue for static‑only critical binaries, others say the backdoor could still act via other privileged components (e.g., dpkg, xz in package managers).
  • Calls for:
    • “All libraries could be malicious” threat modeling for critical software like OpenSSH.
    • Reproducible builds, strict provenance for release tarballs vs VCS trees, and tooling to scan for suspicious behaviors (PLT patching, obfuscation, LD audit hooks).
    • Minimizing distro‑specific patches to security‑critical upstreams, or at least subjecting such patches to heavy security review.
    • Better funding and institutional support for core infrastructure projects to avoid burnout and single‑maintainer situations—though commenters disagree on whether licensing fees or AGPL‑style models are the answer.

Community and governance concerns

  • Many reflect on how norms like “activity == health” and pressure on volunteer maintainers were exploited to install the new maintainer and accelerate releases.
  • Anxiety that similar long‑con supply‑chain compromises may already exist elsewhere, especially with small, under‑reviewed but widely depended‑on libraries.
  • Some fear this will drive more closed, locked‑down hardware/software, others argue it underlines the need for more, not less, open review and multi‑party scrutiny.