OpenSSH’s CVE-2020-14145: the easy fix and the right fix

CVE-2020-14145 is described as a “flaw in OpenSSH where an Observable Discrepancy occurs and leads to an information leak in the algorithm negotiation. This flaw allows a man-in-the-middle attacker to target initial connection attempts, where there is no host key for the server that has been cached by the client.”

Let’s look at the reported flaw in more detail.

When an ssh client tries to establish a connection to an ssh server a list of supported host key algorithms is sent during the protocol handshake. According to RFC 4253, "Each supported (allowed) algorithm must be listed in order of preference, from most to least." When a client performs its first connection to a server that is not yet trusted the order of preference is set to the default (hardcoded) order as the client has no known key to “prefer” its type over other supported types. This allows a man in the middle to estimate if a client already has prior knowledge of the remote host's supported key types. An attacker could use this information to distinguish a client that is connecting for the first time from clients that already have the target host key. The attacker will ignore clients that already know host keys because they would show an error message about a possible man in the middle (MitM) attack. This could alert users or admins or automated scanning tools that an attack is in progress. On the contrary it is normal for new clients to rely on TOFU and to encounter unknown keys so the attacker can attempt a MitM attack without being detected.

Actual security risk: The information leak can only help the attacker to identify better targets for a MitM attack. However exploiting the ssh connection still requires an active attacker that is capable of intercepting and redirecting communications either to DNS or directly to the target server. It also requires a lack of strong security policies for handling host keys (i.e. accepting a forged key).

Can one prevent the described information leak by patching OpenSSH?

Openssh could be patched to “disable” automatic reordering of host key algorithms. However, the reordering of host key algorithms is considered an important security feature. It is required by RFC 4253 and disabling it would break the protocol as defined in that RFCs and may cause compatibility issues.

Damien Miller, upstream openssh developer and recognized security expert commented on this issue as follows:

“First, we consider the automatic ordering of host key algorithms an important feature for security. It provides continuity of trust by clients across changes in default algorithm preference in ssh and servers offering hostkeys of different types.

Disabling this feature wholesale would IMO result in a net loss of security as it would force more connections that already have learned a hostkey to accept a new one of a different algorithm, thereby needlessly exposing them to MITM risk…

...Speaking for myself - I plan to relax the restrictions around UpdateHostkeys' activation, but do not plan to take other action around this "vulnerability". In particular, I do not intend to offer an option to force the use of the default cipher list. IMO too many users would flip it thinking it solved a security problem when the situation is actually far more subtle and the reverse is likely the case.” (source: https://bugzilla.mindrot.org/show_bug.cgi?id=3313#c1)

As explained by Jakub Jelen (jjelen@redhat.com):

“Algorithms are reshuffled based on what key is preferred. This mechanism is used to tell the server what algorithm the client has keys for. If we do not do this, the server will interpret the priority according to the RFC 4253 and if the first algorithm is something else than we have, the client will ultimately fail to verify the hostkey.

If the server does not know what keys the client has, it can not send them. Only one key type and one signature is sent at a time by the server and if it is not the one the client has stored, it will fail to validate it.

For example if we use the default list of algorithms (ECDSA, Ed25519, RSA) and have both ECDSA and RSA keys for a given host, these will not be at the beginning of the list and once the administrators decides to rotate the keys (removing ECDSA keys) the users will see a fatal error because the server will send an Ed25519 key and user can not verify it, while still having other valid RSA key.”

It is evident that OpenSSH cannot be patched to fully mitigate this CVE and at the same time maintain the important security feature provided by the automatic ordering of host key algorithms.

What mitigation does the current upstream patch provide?

Strictly speaking, the upstream patch avoids the reordering of the host key algorithms in a single specific situation: If a host’s public key known to a client matches the type of host key algorithm that is first in the default (hardcoded) order. There is an abundance of other scenarios not covered by the patch and this approach can not be considered a complete solution for the reported CVE.

Recommended solution (workaround) of the issue:

As described above, an attacker would need to intercept and redirect communications either to DNS or directly to the target server to exploit ssh connection. Untrusted network itself represents a far bigger security risk than described CVE and a more comprehensive approach is needed to secure ssh connections. Flaw described in the CVE can be completely mitigated by one of following approaches( additional security provided by algorithm reordering for provisioned hosts is maintained):

• Using centrally managed hostkeys:
  • Using IPA that supports distribution of known hosts on demand using ProxyCommand sss_ssh_knownhostsproxy.
  • The host keys can be provided and maintained by the system administrator directly in /etc/ssh/ssh_known_hosts file. This requires the distribution of this file to all clients and updating it when a new host is added or removed, which makes it more cumbersome.
• The clients can be configured with the CA that signs all centrally managed host keys. This makes it easy to add new hosts, revoke old certificates and much more. For more information see this solution.
• Using GSSAPI Key exchange that allows one to get rid of the host keys altogether. The authenticity of the servers is verified by the Kerberos infrastructure and there are no hostkeys involved at all, preventing possibility to exploit this CVE altogether.