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

Original Article ↗ Hacker News Discussion ↗

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.