Bug 1852930 (CVE-2020-14145)
| Summary: | CVE-2020-14145 openssh: Observable discrepancy leading to an information leak in the algorithm negotiation | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Michael Kaplan <mkaplan> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | ahogbin, crypto-team, cwarfiel, dbelyavs, dwalsh, huzaifas, jfch, jjelen, lkundrak, mattias.ellert, mhavrila, nijoshi, pjakobs, pjasbuti, plautrba, security-response-team, shetze, ssorce, szidek |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-11-09 19:51:07 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1852931, 1882252, 1882253 | ||
| Bug Blocks: | 1852932 | ||
|
Description
Michael Kaplan
2020-07-01 15:34:33 UTC
Created openssh tracking bugs for this issue: Affects: fedora-all [bug 1852931] Mitigation: Always connect to SSH servers with verified host keys to avoid any possibilities of man-in-the-middle attack. 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 Hello Team, Any updates on this? Regards, Nikhil Joshi Hello, Any updates on this? Regards, Nikhil Joshi Hello, Any updates on this? Regards, Nikhil Joshi 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. Statement: 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. 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. Curt, 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. 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 This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-14145 |