OpenSSH 9.3/9.3p1 | Hacker News Reader

OpenSSH 9.3/9.3p1

openssh.com

120 pointsthrow0101c25 comments

Sorry guys, this is my fault. I was going to start builds for the final release candidate for FreeBSD 13.2 in a few hours.

fwiw, releases like this (and especially the notes) give me more confidence in the security of OpenSSH, not less.

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.

Don't forget LibreSSL, which dropped 3.7.1 today.

Maybe they're just triggering major releases whenever they get incoming security issue(s), to reduce release overflow?

OpenBSD is currently in release mode, 7.3 is due out in April. Happens every 6 months like clockwork.

We users of FreeBSD appreciate your hard work Colin!

Thanks! This was a promotion I never wanted, but I'm doing my best to muddle through the release process.

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?

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.

That said, re-implementations are always cool.

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.

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:

Reference: https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

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.

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?".

Well, effort for such undertaking has started by yours truly as a Caddy module/plugin. Here's my announcement blog post: https://www.caffeinatedwonders.com/2022/03/28/new-ssh-server....

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.

Sure, go for it:)

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...

There already are several SSH implementations other than OpenSSH written in all kinds of languages.

There's a few:

https://github.com/gliderlabs/ssh

https://nest.pijul.com/pijul/thrussh

https://github.com/warp-tech/russh

And then there's going the other way...

https://2ton.com.au/HeavyThing/#sshechoserver

Ed: mirage microkernel project has an ocaml ssh lib:

https://github.com/mirage/awa-ssh

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.

Reply on news.ycombinator.com