Piñata proposal for a model of trusted open-source without placing more onus/load on maintainers.
Maintainers keep doing what they do with no new mandates, but with encouragement and support to adopt good practices like commit and release signing, repository hygiene, CI/CD, fuzzing, etc.
This is the nearest of near-misses. Anyone who suggests this was any kind of success is a fool. No system caught this, it was luck and individual heroics. That's not acceptable when unauthorised access to ~every server on the internet is on the table. We need to find a way to do better.
One factor in this incident was deep, unexpected dependency chains. I wish distributions would start taking a more minimalist approach to the options they enable in the default packages they ship.
What fraction of the sshd userbase actually needs Kerberos or SELinux (which also depends on liblzma) enabled? Put that stuff in an alternate package and reduce the exposure for the rest of your users. Fewer dependencies means less attack surface and less supply-chain risk
Few of the mooted software-supply chain defences would have prevented this, as the attacker was a (relatively) long-term maintainer, was not averse to using sockpuppet accounts and was careful to hide their exploit from automated tools.
Worse, many of the solutions being offered increase the workload on maintainers. But maintainer burnout was a key factor in this incident. We need to find a way to support maintainers while being proscriptive or parentalistic.
The "robustness principle" is the most destructive concept in protocol design and implementation of all time. We should be embracing its inverse: strict, explicit state-machines with model-checked proofs
We quietly released the code a little while ago but this is the official announcement of Capslock, our contribution to the supply-chain security conversation.
Capslock is a tool for understanding at high level what a given piece of (Golang) code is capable of and for detecting when an update to a library changes this capability set, to give users a chance to catch supply-chain attacks in progress.
We've just made an OpenSSH release to fix a remotely exploitable RCE vulnerability in ssh-agent's PKCS#11 support (CVE-2023-38408). Details at https://openssh.com/releasenotes.html#9.3p2
Thanks to the Qualys Security Advisory Team for finding and reporting this bug.