Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#67858 - [security] [openssl-1.0] CVE-2020-1968

Attached to Project: Arch Linux
Opened by loqs (loqs) - Wednesday, 09 September 2020, 19:21 GMT
Last edited by freswa (frederik) - Thursday, 10 September 2020, 13:37 GMT
Task Type Bug Report
Category Security
Status Assigned
Assigned To Pierre Schmitz (Pierre)
Levente Polyak (anthraxx)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No


A 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.

Additional info:
* openssl-1.0 1.0.2.u-1
This task depends upon

Comment by Pierre Schmitz (Pierre) - Friday, 11 September 2020, 04:26 GMT
Quoting that same page:

[OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended
support is available for premium support customers:
Comment by loqs (loqs) - Friday, 11 September 2020, 12:31 GMT
From [1]
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.
Although [2] states: Note that this issue only impacts DH ciphersuites and not ECDH ciphersuites.

The patch disables ECDH and DH by marking them as weak. Anonymous DH, DHE and ECDHE and not changed.

Comment by Pascal Ernster (hardfalcon) - Friday, 11 September 2020, 15:47 GMT Comment by loqs (loqs) - Tuesday, 29 September 2020, 00:03 GMT
Patch used by Ubuntu and Debian. This is applied after the patch marking 3DES and RC4 as weak so does not include ciphers already marked as weak by that patch.
Comment by loqs (loqs) - Sunday, 28 February 2021, 19:33 GMT
diff includes fixes for CVE-2020-1968 CVE-2020-1971 CVE-2021-23840 CVE-2021-23841 all sourced from [1]

Comment by Jonas Witschel (diabonas) - Tuesday, 24 August 2021, 14:21 GMT
Another security issue, CVE-2021-3712, that affects OpenSSL 1.0.2 has been disclosed today, the official patch for OpenSSL 1.0.2 can be found at

Additionally, OpenSSL 1.0.2 is affected by the older CVE-2021-23839 as well, the official patch is
Comment by loqs (loqs) - Tuesday, 24 August 2021, 20:04 GMT
@diabonas updating to 1.0.2za would include fixes for all the vulnerabilities apart from CVE-2021-3601?
How is openssl-1.0 1.0.2.u-1 vulnerable to CVE-2021-23839 when it is not built with SSLv2 support?

Attached diff switches to using the github official mirror of openssl to fetch the 1.0.2za signed tag.
Also changes perl to optdepends matching the change in openssl.

nrpe FS#71307 and wvstreams FS#70648 can use openssl (1.1) leaving steam-native-runtime as the only user of openssl-1.0/lib32-openssl-1.0?

Comment by Jonas Witschel (diabonas) - Wednesday, 25 August 2021, 13:14 GMT
> @diabonas updating to 1.0.2za would include fixes for all the vulnerabilities apart from CVE-2021-3601?

This should indeed fix all known vulnerabilities to date. Unfortunately the commit for the 1.0.2za release you referred to (e197135eee4164c33146dad7b96f0d71b8844deb) seems to have been deleted from the repository again, at least I wasn't able to find it right now. It might have been published in error, since OpenSSL 1.0.2 releases are usually not publicly available.

> How is openssl-1.0 1.0.2.u-1 vulnerable to CVE-2021-23839 when it is not built with SSLv2 support?

According to the commit message of the patch: "This has no impact on libssl for modern versions of OpenSSL because there is no protocol support for SSLv2 in these versions. However applications that call RSA_paddin_check_SSLv23 directly, or use the RSA_SSLV23_PADDING mode may still be impacted." I'm not sure how applicable that is to our repository packages, but applying the patch probably doesn't hurt either, so if in doubt I'd add it just to be safe.
Comment by loqs (loqs) - Thursday, 26 August 2021, 22:56 GMT
As the tag has been removed use the individual commits.
openssl-1.0.2.-commits-CVEs.txt lists the commits between OpenSSL_1_0_2u and OpenSSL_1_0_2za then maps the commits to CVEs after removing commits for updating NEWS / CHANGES or version.
PKGBUILD.diff applies those commits, commits taken from github to avoid including the cgit version.
As well as the CVEs this also includes two security fixes that did not match CVE criteria, 'Implement blinding for EC scalar multiplication' and 'Ensure SRP BN_mod_exp follows the constant time path'.
Also change perl to makedepends to match openssl package, not added to optdepends as no perl using scripts are installed by openssl-1.0.