OpenSSH 8.6 is still vulnerable to CVE-2020-14145 and will not be fixed | Hacker News Reader

OpenSSH 8.6 is still vulnerable to CVE-2020-14145 and will not be fixed

github.com

25 pointsralfw9019 comments

So if you're setup with a MitM, and a new client connects (which is presumably an infrequent activity), and they don't check the fingerprint, then you can successfully MitM them. This vulnerability allows a way to filter on step 2 to find only new clients.

So any mitigations that make it impossible to differentiate a new connection from a previously verified one would solve it for now, but doesn't solve the root of the problem. The root issue is that a user is manually accepting an incorrect fingerprint. Currently it's very difficult to determine what the correct one is, which makes it rather worthless to prompt the user in the first place, but at least they have support after 8.0 for doing easier comparison.

So when are we getting the pre-shared fingerprint ease-of-use fixes that actually solve this?

Well,

I looked at both patches and didn't like either one of them. The user 'manfred-kaiser' makes a good point and I have confirmed that he is correct. However the fix he is proposing is not a very good fix. So in my opinion both of the proposed fixes are not sufficient.

The proposed fix: https://github.com/openssh/openssh-portable/commit/b3855ff05...

This proposed fix means OpenSSH is not secure 'by default' and would require HostKeyAlgorithms to be set in the config file. Furthermore... there needs to be an existing public key. Also keep in mind that SSHD refuses to use group/world-accessible keys.

So if this patch is accepted CVE-2020-14145 will continue to work on 'misconfigured' servers.

"It's not our fault, your OpenSSH was misconfigured!"

If I'm understanding the exploit correctly. An attacker could be doing a mitm on the server, and be able to determine if it is a first time connection. Then if it is a first time connection they could intercept and pass along their own key to the client. Since it's the clients first connection they would probably just accept it. Without this technique, the attacker would have to intercept all the traffic and would then be more likely to get caught.

I think it would probably be better if there was a standard for an out of band way to validate the servers public key. Like store a hash in a DNS txt record or something.

Sounds like you are looking for an SSHFP dns record: https://en.wikipedia.org/wiki/SSHFP_record

The fact that these are a special RR type and not TXT means that I can't use them with any of the current DNS hosts I use on any of my domains. :(

> I think it would probably be better if there was a standard for an out of band way to validate the servers public key.

In addition to the mentioned SSHFP record, OpensSSH 8.0 added:

> ssh(1): When prompting whether to record a new host key, accept the key fingerprint as a synonym for "yes". This allows the user to paste a fingerprint obtained out of band at the prompt and have the client do the comparison for you.

* https://www.openssh.com/txt/release-8.0

Algorithmic agility has proved to be a huge area of vulnerability in a lot of security protocols.

I think new protocols should explicitly choose the crypto algorithms and the only way to change them would be to upgrade the protocol as a whole.

I think algorithmic agility is exactly why TLS 1.0 has remained secure for so long (and, to a point, SSL 3 too).

We're already running into compatibility problems with IoT devices and server management boards because of HTTPS and that's just with TLS <1.2 being turned off after many years. I don't believe changing the protocol even faster will benefit most applications. The world has barely implemented http/2 and yet we're already on http/3 based on yet another entirely different protocol.

You'd think that, but you'd be mostly wrong. Many (most, I think?) TLS vulnerabilities have been fixed not by ciphersuite configuration changes but by upgrades to the entire protocol. The most famous configuration workaround --- BEAST prompting people to go from AES to RC4 --- pushed people into an even more grievously insecure cryptosystem.

For the most part, I think negotiable ciphers have been discredited among cryptography engineers. Certainly, it's a design smell in new protocols.

I don't think the problem is that the protocol supports algorithms without versioning it's that it isn't known what the remote side is using on the first connection. Moving this to 4 protocol versions still doesn't tell you which you should use to connect to the remote system, that problem would still need to be solved.

It wouldn’t have to be entirely different, it could just be a major version update. But the vast majority of sysadmins can understand and deploy a major version update. The same cannot be said of specific algorithm ordering tradeoffs or other such detailed configuration.

Again you're just shifting the problem one layer up not solving it. The burden on the sysadmin is it knowing which version to connect with for a particular remote resource. They don't care if that's knowing it's algorithm set 4 or protocol version 4 (which uses algorithm set 4 behind the scenes) since the actual problem is they aren't checking the remote resource to see if it matches prior to connecting.

And just the same as using algorithm set 3 to connect to a MITM proxy for a device that should have used algorithm set 4 you'll also have the same problem using protocol version 3 to a MITM proxy for a device that should have used protocol version 4.

Agreed, it’s definitely best to just never change the protocol. But if you do have to change it someday (quantum cryptanalysis?) it’s better to have a single setting introduced at that point than to have 15 settings with no correct answer introduced at the very beginning.

Description of CVE-2020-14145: https://docs.ssh-mitm.at/CVE-2020-14145.html

Misleading title, “will not be fixed” is not indicated by maintainers.

One of the OpenSSH devs wrote:

> No additional option is needed to change the ordering. If you want to hard-code the default then use the existing HostKeyAlgorithms option.

> Between b3855ff and the more recent change to enable UpdateHostKeys, most users should soon receive the default ordering anyway.

I don't know if this means, that it will not be fixed. It sounds, that there are already some fixes integrated.

But why was the CVE updated to the latest version?

I have tested 8.6 on my machine, and the described exploit still works :-(

Perhaps it is fixed in the next release?

Probably the most simple way to avoid TOFU is to just throw in a simple 1-2 liner into your server creation cloud-init / script / etc

fingerprint the host key -> send an SMS and email of it to you via some APIs -> if they match, then feel free to paste it in during TOFU

If you have a server creation cloud script, you could use an SSH CA to set up server authentication. It requires some extra work (namely finding a way to automatically sign a host key) but it does allow you to avoid TOFU for your entire team rather than just for yourself. Coupled with a second CA for authentication, SSH certificates can be a very powerful way to do SSH server management.

Sending emails or texts is easy, but checking them each time you log in from a new device is cumbersome. I'm too lazy to do the latter and prefer to put in work to set up my complex setup instead, but of course your mileage may vary.

My initial reaction was that this was a pen tester getting a little overzealous. After looking at it a little more that's not great, it's odd that they're not doing more to fix it (although maybe I'm missing something.)

Reply on news.ycombinator.com