Oh, I'm not saying that they shouldn't have released this. Of course they should. It's just creepy how often OpenSSH and OpenSSL security fixes happen just before we do a release.
Probably off topic, but is it worth the trouble to (re)write critical infra software like SSH in memory-safe languages? From the release note this seems a minor issue, but given the importance of SSH in auth, maybe it isn't too crazy to think about the possibilities?
It's not abandoned. I'm still trying to move the project forward. I've just been busy with life. I've moved the repo to an org and put a new name on it: https://github.com/kadeessh/kadeessh. Contributions and help are more than welcome. I'd love to evolve the project, but I need hands and feedback from users, which I haven't received much of.
When I look at CoreDNS, it has something like 573 dependencies (as reported by "go mod graph" and deduped), notably because it imports cloud libraries for AWS, Azure and GCP. That kind of attack surface is something you do not want in a SSH daemon, or a DNS server for that matter.
It couldn't hurt, but the track record for OpenSSH on the vulnerability everybody cares about (remote authentication bypass) is unreal. It's possible the Debian randomness thing was the last major exploitable vulnerability in it.
Also, I think I read that part of the security guarantees in OpenSSH come from its actual software design, as in (but not limited to?) multiprocess design, reducing the blast radius of eventual parsing or logic bugs.
I can't locate a good read on what they do right and how they've progressed since the original design (and maybe 'where' formal proof or memory safety - be it RIIR or good old Frama-C - might be the most impactful). But my googlefu is subpar these days...
Not all bugs are memory bugs. A memory-safe re-implementation would likewise introduce many new bugs, so it would not be necessarily better than the battle-tested current implementation.
If I recall correctly having most of the world relying on a single SSH implementation was raised as a concern by the OpenBSD/OpenSSH developers when HeartBleed happened and OpenBSD forked OpenSSL.
A major security problem in OpenSSH would be a huge issue, as it affects everyone at once.
If someone where to do a reimplementation in a memory-safe language, and let's face it, that's a sly way of saying Rust, it shouldn't be viewed as a replacement for OpenSSH, but as an alternative to existing along side it.
> A major security problem in OpenSSH would be a huge issue, as it affects everyone at once.
It happened once in OpenSSH (in the '00s), and that's it. Ever since, it got hardened. Same with OpenSSL's Heartbleed. We've adapted to these occurrences.
The OpenBSD people have a certain perspective on how to write secure code, which certainly is valuable, but misses low hanging fruit that aren't in their vision as a result of that perspective.
Safer languages are one of the things out of view for them.
At its best, this way of thinking about problems is invaluable because it can cure ills that otherwise affect everyone. OpenBSD has been very enthusiastic about identifying ways programs can avoid having privileges they don't need while retaining ergonomics for example. At its worst though it ignores both categorical improvements like Rust and very niche but targeted security features which don't fit OpenBSD's model like the Certificate Signing Request in PKIX (the document your Let's Encrypt software is just generating internally, once upon a time these were a big deal).
OpenBSD works very hard to enable the code signing your CSR to not need the same privileges as the code doing networking, or the code generating the keys - but it's arguably in vain because there's no need for the CSR to even be generated on the machine with the private key, they've welded a fortified cash box to the vending machine, everybody else just added a card reader. "Now nobody can steal the money!" "What money?".
I agree the probability is low, but it's clearly not 0, nor will it ever be 0. Is it close enough to 0 as to be not worth worrying about? I don't know the answer to that question but I'd guess it's far enough away from zero that it could definitely be a concern.
Especially since we know that upgrades can be quite slow, especially in the consumer space(if they are ever done at all).
Another worry, is now every platform uses OpenSSH (Microsoft, Apple and *nix all use OpenSSH).
22-ish years without a major security problem is a great track record though.
That's not accurate. OpenSSH (and OpenBSD) have a myth around it about lack of security vulnerabilities, but while better than the average, it's wildly exaggerated:
I remember people in the '90s and '00s being smug about still being on ssh.com, because something like 75% of vulnerabilities in SSH implementations for a long time were introduced only into OpenSSH.
Actually reading down those vulnerabilities makes me as confident as ever in it; it has a steady stream of vulnerabilities, but they're almost always things like user enumeration, or a person who already has legitimate access being able to get slightly different access than they were supposed to have. Don't get me wrong, those are still bad, but if you have to go back 20 years to find an actual remote access vulnerability, then I'd say the software is rock solid.
I don't disagree. SSH was already 25 years ago a mature code base with (more importantly) a limited scope and unchanging core requirements.
I think its long life and limited scope is more of a factor to its security success than how good the coders were.
Once you get out of the simple case of "RCE on pre-auth sshd" OpenSSH is no longer looking as good. E.g. CVE-2019-611 is way underhyped, and the fact that it was only discovered in 2019 doesn't speak well for OpenSSH's audit process.
But for "is it safe to open OpenSSH to the world" I'd say "that's safer than anything else, sure". But that's a very narrow (though important) attack vector.
Thanks Colin, this is great! The new unprivileged sshd -G to do auditing of the SSH configuration will be really useful when we start putting SSH daemon auditing into Userify.
