Bug 1176331 - (CVE-2020-1968) VUL-0: CVE-2020-1968: openssl: Raccoon Attack against DH
(CVE-2020-1968)
VUL-0: CVE-2020-1968: openssl: Raccoon Attack against DH
Status: IN_PROGRESS
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Major
: ---
Assigned To: Security Team bot
Security Team bot
https://smash.suse.de/issue/266935/
CVSSv3.1:SUSE:CVE-2020-1968:5.3:(AV:N...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-09-09 13:32 UTC by Marcus Meissner
Modified: 2021-08-17 11:07 UTC (History)
4 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2020-09-09 13:32:40 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.
Comment 1 Vítězslav Čížek 2020-09-09 13:39:04 UTC
(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.
Comment 2 Marcus Meissner 2020-09-09 13:50:21 UTC
Currently I tag all openssl before 1.1.1 as affected, including 1.0 and 0.9.8.
Comment 3 Marcus Meissner 2020-09-09 13:52:16 UTC
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.
Comment 4 Marcus Meissner 2020-09-09 13:53:53 UTC
hmm, it seems that using DH- cipher suites might affect also these other 1.0.2
Comment 5 Vítězslav Čížek 2020-09-09 14:35:20 UTC
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.
Comment 6 Marcus Meissner 2020-09-09 15:14:45 UTC
This sounds like a sensible approach.

I do not think this would be a compatibility risk.
Comment 7 Vítězslav Čížek 2020-09-09 15:30:17 UTC
The static DH ciphersuites were removed in OpenSSL 1.1.0, so anything >= SLE-15 is unaffected.
Comment 8 Vítězslav Čížek 2020-09-11 10:56:54 UTC
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.
Comment 10 Swamp Workflow Management 2020-09-15 13:14:31 UTC
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.
Comment 11 Swamp Workflow Management 2020-09-15 13:16:33 UTC
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.
Comment 12 Marcus Meissner 2020-09-28 09:57:25 UTC
hmm, just to recap, do we want to fix openssl 1.0.2 in SLE12 SP2+ ?
Comment 13 Vítězslav Čížek 2020-09-28 11:40:52 UTC
(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.
Comment 14 Marcus Meissner 2020-09-28 12:02:52 UTC
I also understand openssl 1.1.0 is not affected?

We probably still need openssl1 in SLES 11 (which is 1.0.1 based).
Comment 15 Vítězslav Čížek 2020-09-28 12:57:32 UTC
(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 :-(
Comment 16 Vítězslav Čížek 2020-09-28 15:19:39 UTC
(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.
Comment 20 Swamp Workflow Management 2020-10-05 19:15:20 UTC
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.