Inside the failed attempt to backdoor SSH globally that got caught by chance

Original Article ↗ Hacker News Discussion ↗

A recently uncovered attempt to backdoor OpenSSH via the widely used xz compression library has triggered broader concern over software supply-chain security and the fragility of critical open source infrastructure. Commenters contrast open source and proprietary models, debate the role of systemd and distribution-specific patches in increasing attack surface, and note that the exploit was caught largely by chance rather than by formal security tooling. Many argue that underfunded, volunteer maintainers and a culture of “glueing together” poorly understood components pose systemic risks, prompting proposals ranging from better funding and corporate responsibility to liability regimes and more aggressive sandboxing.

Open Source vs Proprietary Security

  • Debate over whether open source is safer than closed source:
    • Pro-open-source: backdoors and vulnerabilities can be spotted by anyone; example NSA-related key in Windows mentioned; this xz backdoor was ultimately caught in the open.
    • Skeptical view: “enough eyeballs” is misleading; you need the right (often scarce, expensive) eyeballs. Source availability also helps attackers find bugs.
    • Counterpoint: proprietary software can hide backdoors indefinitely; reverse engineering and fuzzing help, but visibility is worse than with OSS.

Systemd, libsystemd, and Attack Surface

  • Some blame systemd’s breadth (“does too much,” increases attack surface; libsystemd dragged xz into sshd).
  • Others counter:
    • The problematic link to libsystemd was a downstream OpenSSH patch in Debian/Fedora, not required by OpenSSH.
    • Many systemd services don’t link libsystemd; its dependency tree is small compared to glibc.
    • Even without systemd, any widely used library could have been targeted.

Detection, Tooling, and Security Industry

  • The backdoor was found via performance anomalies in sshd.
  • Automated tools (e.g., valgrind in distro pipelines) had already flagged odd behavior, but warnings were effectively ignored or not investigated deeply.
  • Some criticize the security industry for focusing on complex, low-probability issues while missing huge supply-chain holes; others note similar attacks (e.g., SolarWinds) were detected far later.

Maintainers, Abuse, and Funding

  • Recurrent theme: critical infrastructure relies on small, often unpaid projects with burnout-prone maintainers.
  • Corporate users frequently contribute nothing back; some call this “parasitic,” others argue wide adoption itself has value.
  • Suggested remedies:
    • Companies sponsoring maintainers or funding foundations.
    • Dedicated teams (via Linux Foundation–style bodies) to maintain “deep stack” dependencies that individual firms won’t fund directly.
    • Concerns that money can skew priorities and turn volunteer projects into stressful jobs.

Liability, Regulation, and Licensing

  • Proposal: introduce legal liability and insurance for critical OSS components, driving funding via risk reduction.
  • Strong pushback: would chill free contributions, is hard to implement fairly, and clashes with “no warranty” norms and free speech.
  • EU Cyber Resilience Act is cited as moving in this direction; some fear it will drive small projects and solo developers out of business.

Sandboxing, OS Design, and Isolation

  • Several argue current Unix/Windows-style models are outdated:
    • Point to SELinux, app sandboxing (macOS, iOS, Android, ChromeOS), QubesOS-style compartmentalization.
    • Frustration that most desktop/server software doesn’t sandbox itself, even when mechanisms exist.
  • Others note sandboxing can limit functionality and tooling is poor, so many apps stay unsandboxed.

Prevalence of Similar Backdoors / Threat Actors

  • Worry that this sophisticated, long-term xz compromise implies more undiscovered backdoors.
  • Counter: such an operation is extremely hard; the fact it was caught relatively quickly suggests this might be rare.
  • Debate over “nation-state” vs “bored kid”:
    • Some see the patience and complexity as clearly state-level.
    • Others say young, highly skilled individuals could also do this; attacker identity doesn’t change the defense posture.

Distributions, Monoculture, and Impact

  • Distros that patched sshd to use systemd notifications (Debian, Fedora) were closer to being affected; rolling/testing branches actually shipped malicious xz for a short time.
  • Arch shipped the malicious xz but wasn’t vulnerable because its sshd wasn’t patched that way; BSDs and non-systemd distros generally unaffected.
  • This is used both:
    • As a critique of “Linux + systemd” monoculture.
    • And as a caution about downstream patching of security-critical software.

Social Engineering and Contributor Identity

  • The attacker gained maintainer status via sustained social engineering and fake community pressure.
  • Several commenters call for better “social tooling”:
    • Visibility into contributor history, activity patterns, and cross-project presence.
    • Stronger norms around trusting new maintainers and scrutinizing unusual build/test changes.