XZ backdoor story – Initial analysis

Original Article ↗ Hacker News Discussion ↗

A deeply engineered backdoor found in the widely used xz compression library has triggered broad concern about open‑source supply‑chain security, because it nearly led to remote compromise of SSH servers on major Linux distributions. Commenters examine both the technical sophistication of the exploit—multi‑stage build‑time obfuscation, ELF/GOT manipulation, and ifunc abuse—and the long social engineering campaign that let an attacker effectively take over project maintenance. Many argue this incident should prompt stricter build and release practices, clearer separation of build/test artifacts, and better support for overburdened maintainers, while acknowledging that well‑resourced actors may already be running similar operations elsewhere.

Technical nature of the backdoor

  • Backdoor relied on glibc ifunc, ELF/GOT manipulation, and sshd’s eager binding; it lived in code paths not normally executed, using ifunc resolvers and early relocation as the entry point.
  • It included a custom ELF parser and x86 disassembler plus a trie-based string matcher to avoid literal strings, increasing stealth but adding substantial overhead (hundreds of ms per ssh connection).
  • Multiple layers of obfuscation in build scripts and test data blobs staged payload extraction and injection; some commenters think this was over‑engineered and made detection easier via performance and valgrind anomalies.
  • Details like use of Ed448 and heavy string obfuscation likely contributed to slowness; exact contribution vs ELF parsing is debated.

Build systems, autotools, and supply chain

  • Strong criticism of current build chains: autotools, m4, shell scripts, and vendored files create many hiding places.
  • Disagreement on where the “first” malicious stage lived: some blame generated autotools output, others emphasize an m4 macro plus extra tarball files that distros consumed even after rerunning autoconf.
  • Suggestions include:
    • More declarative, limited-power build systems and reproducible generation of all blobs.
    • Strict linkage between release tarballs and VCS tags.
    • Separating build and test steps, or excluding test binaries from the build path.
  • Others counter that restricting build languages (e.g., banning m4/C or “simple declarative” configs) tends to add more complexity, not less.

Mitigations and hardening ideas

  • Ideas: per-library GOTs sealed read-only post-link; R^X protections; static linking for critical daemons (e.g., sshd); disabling ifunc where possible; early binding / full RELRO.
  • Counterpoints: lazy linking and dlopen make sealing GOT hard; once malicious code runs in-process, GOT protections are bypassable (e.g., via /proc/self/mem).
  • Library sandboxing is seen as largely unsolved; only researchy capability systems and process-level sandboxes really help.

Social engineering and project governance

  • Many see the most disturbing aspect as the long-term social takeover: persistent pressure on an overburdened maintainer, then gradual control of releases.
  • Concern that this will raise barriers for new or anonymous contributors; others argue identity checks (LinkedIn, IDs, “verified” statuses) are ineffective against state actors and harmful to privacy.
  • Some propose distinguishing unpaid open-source “developers” from paid “suppliers” with contractual obligations; security should come from code review and provenance, not identity alone.

Attribution, scale, and impact

  • Many infer a state-backed team given the planning, opsec, and patience; others note that highly skilled criminals or obsessive individuals could also manage this.
  • Time-zone and workday analysis has been used to speculate about origin, but commenters stress this is inconclusive.
  • Impact assessments differ: some note only testing / pre-release distros were affected; others emphasize this was a near-miss global sshd compromise, “averted by chance.”
  • Thread repeatedly raises the likelihood of other, undetected supply-chain backdoors, especially in closed-source software where auditing is rarer.