XZ backdoor story – Initial analysis

Original Article ↗ Hacker News Discussion ↗

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.