Bugzilla – Bug 1176331
VUL-0: CVE-2020-1968: openssl: Raccoon Attack against DH
Last modified: 2024-05-23 15:07:59 UTC
CVE-2020-1968 https://raccoon-attack.com/ Raccoon is a timing vulnerability in the TLS specification that affects HTTPS and other services that rely on SSL and TLS. These protocols allow everyone on the Internet to browse the web, use email, shop online, and send instant messages without third-parties being able to read the communication. Raccoon allows attackers under certain conditions to break the encryption and read sensitive communications. The vulnerability is really hard to exploit and relies on very precise timing measurements and on a specific server configuration to be exploitable. Attack Overview Diffie-Hellman (DH) key exchange is a well-established method for exchanging keys in TLS connections. When using Diffie-Hellman, both TLS peers generate private keys at random (a and b) and compute their public keys: ga mod p and gb mod p. These public keys are sent in the TLS KeyExchange messages. Once both keys are received, both the client and server can compute a shared key gab mod p - called premaster secret - which is used to derive all TLS session keys with a specific key derivation function. Our Raccoon attack exploits a TLS specification side channel; TLS 1.2 (and all previous versions) prescribes that all leading zero bytes in the premaster secret are stripped before used in further computations. Since the resulting premaster secret is used as an input into the key derivation function, which is based on hash functions with different timing profiles, precise timing measurements may enable an attacker to construct an oracle from a TLS server. This oracle tells the attacker whether a computed premaster secret starts with zero or not. For example, the attacker could eavesdrop ga sent by the client, resend it to the server, and determine whether the resulting premaster secret starts with zero or not. Learning one byte from a premaster secret would not help the attacker much. However, here the attack gets interesting. Imagine the attacker intercepted a ClientKeyExchange message containing the value ga. The attacker can now construct values related to ga and send them to the server in distinct TLS handshakes. More concretely, the attacker constructs values gri*ga, which lead to premaster secrets gri*b*gab. Based on the server timing behavior, the attacker can find values leading to premaster secrets starting with zero. In the end, this helps the attacker to construct a set of equations and use a solver for the Hidden Number Problem (HNP) to compute the original premaster secret established between the client and the server.
(https://www.openssl.org/news/secadv/20200909.txt) OpenSSL Security Advisory [09 September 2020] ============================================= Raccoon Attack (CVE-2020-1968) ============================== Severity: Low The Raccoon attack exploits a flaw in the TLS specification which can lead to an attacker being able to compute the pre-master secret in connections which have used a Diffie-Hellman (DH) based ciphersuite. In such a case this would result in the attacker being able to eavesdrop on all encrypted communications sent over that TLS connection. The attack can only be exploited if an implementation re-uses a DH secret across multiple TLS connections. Note that this issue only impacts DH ciphersuites and not ECDH ciphersuites. OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH secret and does not implement any "static" DH ciphersuites. OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH ciphersuite is used. These static "DH" ciphersuites are ones that start with the text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names for these ciphersuites all start with "TLS_DH_" but excludes those that start with "TLS_DH_anon_". OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS connections in server processes unless the SSL_OP_SINGLE_DH_USE option was explicitly configured. Therefore all ciphersuites that use DH in servers (including ephemeral DH) are vulnerable in these versions. In OpenSSL 1.0.2f SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off as a response to CVE-2016-0701. Since the vulnerability lies in the TLS specification, fixing the affected ciphersuites is not viable. For this reason 1.0.2w moves the affected ciphersuites into the "weak-ssl-ciphers" list. Support for the "weak-ssl-ciphers" is not compiled in by default. This is unlikely to cause interoperability problems in most cases since use of these ciphersuites is rare. Support for the "weak-ssl-ciphers" can be added back by configuring OpenSSL at compile time with the "enable-weak-ssl-ciphers" option. This is not recommended. OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w. If upgrading is not viable then users of OpenSSL 1.0.2v or below should ensure that affected ciphersuites are disabled through runtime configuration. Also note that the affected ciphersuites are only available on the server side if a DH certificate has been configured. These certificates are very rarely used and for this reason this issue has been classified as LOW severity. This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram and Juraj Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in order to allow co-ordinated disclosure with other implementations.
Currently I tag all openssl before 1.1.1 as affected, including 1.0 and 0.9.8.
From the page: OpenSSL assigned the issue CVE-2020-1968. OpenSSL does use fresh DH keys per default since version 1.0.2f (which made SSL_OP_SINGLE_DH_USE default as a response to CVE-2016-0701). Therefore, the attack mainly affects OpenSSL 1.0.2 when a DH certificate is in use, which is rare. OpenSSL 1.1.1 never reuses a DH secret and does not implement any "static" DH ciphersuites. To mitigate the attack, the developers moved all remaining DH cipher suites into the "weak-ssl-ciphers" list. In addition, motivated by this research, the developers also activated the fresh generation of EC ephemeral keys in OpenSSL 1.0.2w. Please refer to the OpenSSL Security Advisory.
hmm, it seems that using DH- cipher suites might affect also these other 1.0.2
Yes, I think that static DH ciphersuites are generally a problem, they aren't common though. Regarding the other vulnerable path, SLE-12 has 1.0.2j, which doesn't reuse DH secret over connections. Older openssl, such as 1.0.1 and 0.9.8, however, seem to do that. We might set SSL_OP_SINGLE_DH_USE on by default in these to mitigate this vector. (That's what was done in 1.0.2f, where it even cannot be disabled) Fortunately, the Raccoon attack sounds rather impractical.
This sounds like a sensible approach. I do not think this would be a compatibility risk.
The static DH ciphersuites were removed in OpenSSL 1.1.0, so anything >= SLE-15 is unaffected.
I submitted a fix for openssl 0.9.8, the DH secret is now never reused, new DH keys are generated for each connection (as described in comment 5). The static DH ciphersuites are still available, but they aren't present in our DEFAULT_SUSE cipherlist.
SUSE-SU-2020:2634-1: An update that fixes two vulnerabilities is now available. Category: security (important) Bug References: 1153785,1176331 CVE References: CVE-2019-1563,CVE-2020-1968 JIRA References: Sources used: SUSE Linux Enterprise Server for SAP 12-SP5 (src): compat-openssl098-0.9.8j-106.21.1 SUSE Linux Enterprise Server for SAP 12-SP4 (src): compat-openssl098-0.9.8j-106.21.1 SUSE Linux Enterprise Server for SAP 12-SP3 (src): compat-openssl098-0.9.8j-106.21.1 SUSE Linux Enterprise Server for SAP 12-SP2 (src): compat-openssl098-0.9.8j-106.21.1 SUSE Linux Enterprise Module for Legacy Software 12 (src): compat-openssl098-0.9.8j-106.21.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
SUSE-SU-2020:14491-1: An update that fixes one vulnerability is now available. Category: security (important) Bug References: 1176331 CVE References: CVE-2020-1968 JIRA References: Sources used: SUSE Linux Enterprise Server 11-SP4-LTSS (src): openssl-0.9.8j-0.106.34.1 SUSE Linux Enterprise Point of Sale 11-SP3 (src): openssl-0.9.8j-0.106.34.1 SUSE Linux Enterprise Debuginfo 11-SP4 (src): openssl-0.9.8j-0.106.34.1 SUSE Linux Enterprise Debuginfo 11-SP3 (src): openssl-0.9.8j-0.106.34.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
hmm, just to recap, do we want to fix openssl 1.0.2 in SLE12 SP2+ ?
(In reply to Marcus Meissner from comment #12) > hmm, just to recap, do we want to fix openssl 1.0.2 in SLE12 SP2+ ? I'd leave it as it is. There we have 1.0.2j, which contains https://github.com/openssl/openssl/commit/c5b831f21d0d29d1e517d139d9d101763f60c9a2. The DH secret is not reused between TLS sessions, unless a static DH ciphersuite is in use.
I also understand openssl 1.1.0 is not affected? We probably still need openssl1 in SLES 11 (which is 1.0.1 based).
(In reply to Marcus Meissner from comment #14) > I also understand openssl 1.1.0 is not affected? (In reply to Vítězslav Čížek from comment #7) > The static DH ciphersuites were removed in OpenSSL 1.1.0, so anything >= > SLE-15 is unaffected. It's not affected. It's not mentioned in the upstream advisory, as it's out of upstream support. > We probably still need openssl1 in SLES 11 (which is 1.0.1 based). Yes, I missed that one. I thought we got rid of 1.0.1 for good :-(
(In reply to Marcus Meissner from comment #14) > We probably still need openssl1 in SLES 11 (which is 1.0.1 based). Submitted in 227421.
SUSE-SU-2020:14511-1: An update that fixes one vulnerability is now available. Category: security (important) Bug References: 1176331 CVE References: CVE-2020-1968 JIRA References: Sources used: SUSE Linux Enterprise Server 11-SECURITY (src): openssl1-1.0.1g-0.58.27.2 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.
All done, closing.