PuTTY vulnerability vuln-dynamic-hostkey-info-leak

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

PuTTY 0.68 introduced a dynamic policy for setting the host key preference order in the SSH_MSG_KEXINIT message. Host key types for which the client already has a stored host key are promoted to the top of the list. This ensures that if the client does have at least one stored key for the server, then one of those keys will be used in the connection.

Without this option, if you already had a host key stored, and the server acquired a new key higher up PuTTY's default preference order (e.g. an sshd upgrade caused an Ed25519 key to be generated when previously the host only had RSA), the client would ask you to confirm the new key, even though you already knew a key you could use to talk to that host safely.

However, this policy has a downside as well as an upside. The list of host key types is sent in cleartext in the first SSH_MSG_KEXINIT message of the connection. So a network snooper eavesdropping on all your SSH connections will notice the different orders of host key preference used for different hosts, and can use those to make a guess about which servers you already have host keys for, and which ones you're connecting to for the first time.

So, if you're the kind of user who clicks "accept" to new host keys without checking them out of band (the TOFU policy – Trust On First Use), and if an active attacker is intending to substitute fake host in your SSH connections, then they might be able to use this clue to substitute fake keys for only the hosts you don't already have keys for, which might reduce their risk of being detected when performing that attack.

PuTTY 0.74 comes with a new configuration option in the SSH > Host keys panel: “Prefer algorithms for which a host key is known”. This option is on by default. If you turn it off, you can revert to the pre-0.68 policy in which the same host key preference order is used regardless of the keys you already have cached for a given server.

Our analysis is that this is a choice with pros and cons on each side. Taking several classes of user in turn:

The “model” user who checks host keys out of band:

We think this user benefits from the default dynamic policy. (These are the users for whom we introduced it in the first place.)

Checking host keys out of band is awkward, and sometimes not possible (if you can't contact the admin of the server by other methods at the time you need to make the connection). So it's desirable to avoid it whenever possible.

The information leak is not important to this class of user, because an attacker substituting a phony host key will be detected anyway by the out-of-band check.

The “oblivious” user who always clicks yes to new host keys (but not to changed ones of the same type):

For this user, it makes very little difference which option they select!

Suppose they turn off the dynamic host key policy, and the active attacker tries to fake a host key for an already-known server, in a case where they would otherwise have been warned off by a changed preference order.

In most cases this will mean that the server does not provide the host key type at the top of PuTTY's preference list (or else the preference order would have been the same even with the dynamic policy enabled). So the attacker could substitute that topmost host key type in any case, and still not be detected.

The “semi-oblivious” user who clicks yes to new hosts, but checks up on old hosts offering new key types:

This is the class of user who is likely to benefit from turning the dynamic policy off, because in this case, the attacker will be misled into trying to attack a connection to an already-known server; they will substitute a host key of a type the server does not provide; and the semi-oblivious user will notice, and check up on it, and detect the attack.

All of this analysis assumes that the user has not meddled with the default host key preference order in the PuTTY configuration. If they do – and, especially, if they change it differently depending on the saved session – then they can probably completely confuse this hypothetical attacker in any case.

This potential vulnerability was reported to us by the Competence Center for IT security at the FZI Research Center for Information Technology. They have assigned it the id FZI-2020-5, and Mitre assigned it CVE-2020-14002. Here is their own writeup of the issue.