OpenSSH Backdoors
OpenSSH backdoors and the recent xz-utils supply-chain attack are prompting renewed scrutiny of the “many eyes” theory of open source security. Commenters weigh whether volunteer-led projects can match or exceed the security of commercial, closed-source alternatives, highlighting risks from unvetted maintainers, insider threats, and complex dependency chains. Proposals range from stricter contribution models and better sandboxing to safer languages and formal verification, but there is broad agreement that current software and OS practices make it hard to reliably prevent subtle backdoors or “bugdoors.”
Many-eyes theory and bug discovery
- Several comments challenge “many eyes” / Linus’s Law as a security guarantee.
- Empirical arguments: bug-finding doesn’t scale linearly with reviewers; 2–4 focused reviewers may be optimal.
- High-profile bugs like Heartbleed and OpenSSL code quality are cited as counterexamples to the mantra that open source visibility alone yields security.
- Point that “eyeballs weren’t really looking” until incidents force attention.
Open source vs commercial security
- Debate over whether a volunteer-driven project like OpenSSH can match or exceed commercial security.
- One camp: open source is safer; closed vendors have cost pressure, weaker review, and are attractive targets for insider compromise.
- Others counter: corporations with massive infrastructure (cloud providers, etc.) run very advanced, process-heavy security programs and rarely suffer catastrophic breaches; they invest in access control, logging, and multi-party approvals.
- Some argue volunteer-led infrastructure still ends up more secure in practice; others say both FOSS and corporate efforts are essential and complementary.
XZ/OpenSSH backdoor specifics and impact
- Clarification that vanilla OpenSSH does not depend on xz; the backdoor hit Linux distros that patched in libsystemd, which in turn depended on xz.
- Strong view that expecting OpenSSH maintainers to vet transitive dependencies added by distributions is unreasonable; focus should be on distro processes.
- References to analyses of the payload: it hooks SSH RSA handling and uses a crafted “public key” as an encrypted command channel for remote code execution.
Historical backdoors and “bugdoors”
- Examples mentioned: Juniper firmware SSH backdoor, UnrealIRCd, ProFTPD, socat, a 2003 Linux kernel “bugdoor” attempt, UnrealIRCd backdoor challenge, and alleged but unproven OpenBSD IPsec backdoor.
- Consensus that “bugdoors” (malicious bugs) are plausible and may already have been patched unnoticed.
- Observation: backdoors in widely deployed components (like OpenSSH) are extremely high-stakes and may be more about disruption than targeted access.
Process, tooling, and defenses
- Tests and code coverage alone won’t prevent intentional backdoors.
- Suggestions include: better sandboxing/containers with sane defaults, OS-level permission/IAM-style systems, reduced SSH usage in production, and more specialized tools instead of raw shells.
- Desire for formal verification and rigor similar to certain microkernel projects, but recognition that full formal methods are hard; safer languages (Rust, Ada) are suggested as more realistic improvements.
- Concern that compilers and complex dependencies (e.g., init systems) widen the supply-chain attack surface.