Bug 1852930 (CVE-2020-14145) - CVE-2020-14145 openssh: Observable discrepancy leading to an information leak in the algorithm negotiation
Summary: CVE-2020-14145 openssh: Observable discrepancy leading to an information leak...
Alias: CVE-2020-14145
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1852931 1882252 1882253
Blocks: 1852932
TreeView+ depends on / blocked
Reported: 2020-07-01 15:34 UTC by Michael Kaplan
Modified: 2021-11-09 19:51 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in OpenSSH in versions 5.7 through 8.3, 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.
Clone Of:
Last Closed: 2021-11-09 19:51:07 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2021:4368 0 None None None 2021-11-09 18:29:03 UTC

Description Michael Kaplan 2020-07-01 15:34:33 UTC
The client side in OpenSSH 5.7 through 8.3 has an Observable Discrepancy leading to an information leak in the algorithm negotiation. This allows man-in-the-middle attackers to target initial connection attempts (where no host key for the server has been cached by the client).



Comment 1 Michael Kaplan 2020-07-01 15:34:51 UTC
Created openssh tracking bugs for this issue:

Affects: fedora-all [bug 1852931]

Comment 6 Huzaifa S. Sidhpurwala 2020-07-08 04:33:46 UTC

Always connect to SSH servers with verified host keys to avoid any possibilities of man-in-the-middle attack.

Comment 11 Sebastian Hetze 2020-11-17 10:52:27 UTC
Hi *,

I do not agree with the low impact classification for this bug.

In fact, the information leak allows MitM to filter out target hosts that have stored a previously exchanged host-key and attack only those hosts that go through the initial key exchange procedure.

Most users have limited capabilities to validate the host key fingerprint and therefor accept the first key presented to them.

With the CVE-2020-14145 it is significantly less likely that the MitM will be discovered. Or on the other hand: if this bug is fixed, the MitM faces a substantial risk to be discovered by users that get a warning about host key changed.

For this reason, it is highly desired that this bug will be fixed.

Best regards,

  Sebastian Hetze

Comment 14 Nikhil Joshi 2020-12-01 08:29:12 UTC
Hello Team,

Any updates on this?

Nikhil Joshi

Comment 16 Nikhil Joshi 2020-12-08 08:08:22 UTC

Any updates on this?

Nikhil Joshi

Comment 17 Nikhil Joshi 2021-01-27 14:18:08 UTC

Any updates on this?

Nikhil Joshi

Comment 23 Simo Sorce 2021-02-22 14:40:07 UTC
I would also add, that customers can simply work around this issue, by standardizing on a single host key type, and setting their set of algorithms to cover exclusively that key type. at that point there is no difference between preferred algorithms in the two cases.

Comment 34 Huzaifa S. Sidhpurwala 2021-02-25 07:01:52 UTC

This is a flaw in OpenSSH, which allows a man in the middle attack to determine, if a client already has prior knowledge of the remote hosts fingerprint. An attacker could use this information to ignore clients, which will show an error message during an man in the middle attack, while new clients can be intercepted without alerting them of the man in the middle attack.

This essentially means that this flaw can help attacker's identify targets an MITM attack. However such a attack would still require the attacker to either have control over DNS or control over the network traffic.

If the network is untrusted, Red Hat suggests the use ssh certificates for even more confidence and less human factor involved or gssapi key exchange, where kerberos is used to verify identity of the server.

Comment 40 Simo Sorce 2021-03-15 13:17:36 UTC
Given there is an upstream patch I am ok backporting it if there is strong customer demand.
I still think it is not a great idea. But I will not stand in the way when upstream speaks.

Comment 59 Simo Sorce 2021-05-21 14:40:09 UTC
as explained *several* times, it keeps being pushed because it is a highly disruptive change, and the severity is really low, regardless of what customers think.
To fix this "issue" a change that breaks the protocol as defined in RFCs is needed, and this comport compatibility issues.
At the same time, customers can *easily* work around the problem by setting a company policy of using only one specific key type.

So our decision is that for RHEL-7 the impact if this change is not warrnted, as the severity of the issues is not enough to overcome the compatibility issue this fix may create for *all* RHEL-7 customers.

Please communicate with your customer to set expectations.

Comment 62 errata-xmlrpc 2021-11-09 18:29:01 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2021:4368 https://access.redhat.com/errata/RHSA-2021:4368

Comment 63 Product Security DevOps Team 2021-11-09 19:51:04 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):


Note You need to log in before you can comment on or make changes to this bug.