CVE-2020-14145: OpenSSH Information Disclosure Vulnerability

CVE-2020-14145 Overview

CVE-2020-14145 is an information disclosure vulnerability in the OpenSSH client affecting versions 5.7 through 8.4, with some reports indicating versions 8.5 and 8.6 are also affected. The vulnerability exists in the client-side algorithm negotiation process, where an observable discrepancy allows attackers to determine whether a client has previously connected to a specific server. This information leak enables man-in-the-middle (MITM) attackers to target initial connection attempts where no host key for the server has been cached by the client.

Critical Impact

Attackers positioned in a network path can exploit the algorithm negotiation timing to identify first-time SSH connections, enabling targeted MITM attacks against users connecting to new servers without cached host keys.

Affected Products

• OpenBSD OpenSSH versions 5.7 through 8.6
• NetApp AFF A700s Firmware
• NetApp Active IQ Unified Manager (VMware vSphere)
• NetApp HCI Management Node
• NetApp ONTAP Select Deploy Administration Utility
• NetApp SolidFire
• NetApp SteelStore Cloud Integrated Storage
• NetApp HCI Compute Node
• NetApp HCI Storage Node

Discovery Timeline

• 2020-06-29 - CVE-2020-14145 published to NVD
• 2025-12-18 - Last updated in NVD database

Technical Details for CVE-2020-14145

Vulnerability Analysis

The vulnerability stems from an observable discrepancy in the SSH client's algorithm negotiation behavior during the initial connection handshake. When an OpenSSH client connects to a server, it proposes a list of supported cryptographic algorithms for key exchange, encryption, and MAC operations. The order and content of these algorithm lists differ depending on whether the client has a cached host key for the target server.

This behavioral difference creates a side-channel that attackers can exploit. When the client has previously connected to a server and cached its host key, the algorithm negotiation process follows a different pattern compared to first-time connections. An attacker observing the network traffic can detect this discrepancy without needing to decrypt the SSH traffic.

The practical impact is significant for initial connections: attackers can identify users connecting to servers for the first time and mount MITM attacks with a higher probability of success, as these connections lack the protection of a pre-cached host key verification.

Root Cause

The root cause is the observable difference in algorithm preference ordering based on the client's known_hosts cache state. The OpenSSH client implementation did not adequately mask the distinction between connections to known versus unknown hosts during the algorithm negotiation phase. This timing and ordering discrepancy violates the principle of avoiding information leakage through observable behavior variations (CWE-203: Observable Discrepancy).

Attack Vector

The attack requires a network-based man-in-the-middle position between the SSH client and the target server. The attacker observes the algorithm negotiation packets during the SSH handshake to determine whether the client has previously connected to the server.

The attack flow proceeds as follows:

1. The attacker positions themselves in the network path between the victim and the SSH server
2. When the victim initiates an SSH connection, the attacker captures the algorithm negotiation packets
3. By analyzing the algorithm list ordering and timing characteristics, the attacker determines if this is a first-time connection
4. If the connection is identified as a first-time connection (no cached host key), the attacker proceeds with a MITM attack
5. The attacker can present their own host key, which the client may accept since there is no cached key to compare against

For detailed technical information about the exploitation mechanism, refer to the SSH-MITM CVE-2020-14145 Documentation and the FZI Security Article on Information Leak.

Detection Methods for CVE-2020-14145

Indicators of Compromise

• Unexpected SSH host key change warnings when connecting to known servers
• Network traffic anomalies indicating interception between SSH clients and servers
• Presence of unauthorized certificates or keys in connection logs
• Users reporting host key verification failures for previously trusted servers

Detection Strategies

• Monitor for SSH connection attempts that fail host key verification followed by successful connections with different keys
• Implement network-level detection for MITM attack patterns in SSH traffic
• Deploy SSH fingerprint monitoring to detect unauthorized key presentations
• Analyze SSH client logs for algorithm negotiation anomalies

Monitoring Recommendations

• Enable detailed SSH client logging to capture algorithm negotiation details
• Implement centralized logging for SSH connection events across the organization
• Deploy network intrusion detection systems (IDS) with SSH traffic analysis capabilities
• Regularly audit known_hosts files for unexpected modifications or new entries

How to Mitigate CVE-2020-14145

Immediate Actions Required

• Upgrade OpenSSH to version 8.4P1 or later, which includes the fix for this vulnerability
• Implement strict host key checking (StrictHostKeyChecking yes) in SSH client configurations
• Pre-populate known_hosts files with verified server host keys before initial connections
• Train users to verify host key fingerprints through out-of-band channels for new connections

Patch Information

The vulnerability has been addressed in the OpenSSH codebase. The relevant fix can be found in OpenSSH Commit b3855ff. Organizations should update to patched versions as documented in the GitHub OpenSSH Port Comparison between versions 8.3P1 and 8.4P1.

For NetApp products, refer to the NetApp Security Advisory NTAP-20200709-0004 for specific guidance. Gentoo Linux users should consult Gentoo GLSA 2021-05-35 Advisory.

Workarounds

• Configure SSH clients with StrictHostKeyChecking yes to prevent automatic acceptance of unknown host keys
• Distribute verified host keys via secure channels (e.g., configuration management systems) before first connections
• Use SSH certificate-based authentication with a trusted Certificate Authority to eliminate reliance on known_hosts caching
• Implement network segmentation to reduce MITM attack opportunities

# SSH client hardening configuration (~/.ssh/config or /etc/ssh/ssh_config)
Host *
    StrictHostKeyChecking yes
    UpdateHostKeys yes
    VerifyHostKeyDNS yes