OpenSSL has issued an advisory on September 9: https://www.openssl.org/news/secadv/20200909.txt Ubuntu has issued an advisory for this on September 16: https://ubuntu.com/security/notices/USN-4504-1 They have a patch for 1.0.2, which hopefully will work for 1.1.0. The Cauldron openssl package (1.1.1) is not affected.
Whiteboard: (none) => MGA7TOO
It looks sensible to assign this to NicolasS as having committed both packages relatively recently.
Assignee: bugsquad => nicolas.salgueroSource RPM: openssl-1.1.0j-1.mga7.src.rpm, compat-openssl10-1.0.2r-1.mga7.src.rpm => openssl-1.1.0j-1.mga7.src.rpm, compat-openssl10-1.0.2r-1.mga7.src.rpm,compat-openssl10-1.0.2u-2.mga8.src.rpm
Hi, According to https://www.suse.com/support/kb/doc/?id=000019697, openssl 1.1.0 may not be vulnerable: """ openssl 1.1.1 versions as shipped in SLES 15 SP2 and SLES 12 SP4 and SP5 are not affected as they do not contain the problematic cipher suites. openssl 1.1.0 versions as shipped in SLES 15 GA and SLES 15 SP1 are not affected as they do not contain the problematic cipher suites. openssl 1.0.2 versions shipped in SLES 12 SP2 and newer, and as legacy in SLES 15 are affected, if a static DH cipher is in use by a TLS server. openssl 0.9.8 versions are affected, if either static DH or ephemeral DH cipher (due to the secret reuse) is in use by a TLS server. """ Moreover, the patch for version 1.0.2 does not apply at all in version 1.1.0. Best regards, Nico.
Thanks. Upstream helpfully didn't even bother to determine whether it was affected.
Version: Cauldron => 7Whiteboard: MGA7TOO => (none)Source RPM: openssl-1.1.0j-1.mga7.src.rpm, compat-openssl10-1.0.2r-1.mga7.src.rpm,compat-openssl10-1.0.2u-2.mga8.src.rpm => compat-openssl10-1.0.2r-1.mga7.src.rpmSummary: openssl, compat-openssl10 new security issue CVE-2020-1968 => compat-openssl10 new security issue CVE-2020-1968
The build fails on the BS with the following error: """ ../util/shlib_wrap.sh ./ssltest -test_cipherlist testing SSLv3 cipher list order: ok testing TLSv1 cipher list order: ok Testing cipherlist order only. Ignoring all other options. WARNING: can't open config file: /etc/pki/tls/openssl.cnf test sslv2 Testing was requested for a disabled protocol. Skipping tests. test sslv2 with server authentication Testing was requested for a disabled protocol. Skipping tests. test sslv2 with client authentication Testing was requested for a disabled protocol. Skipping tests. test sslv2 with both client and server authentication Testing was requested for a disabled protocol. Skipping tests. test sslv3 Available compression methods: NONE 140318884004160:error:140E6118:SSL routines:SSL_CIPHER_PROCESS_RULESTR:invalid command:ssl_ciph.c:1381: 140318884004160:error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers:ssl_lib.c:1983: 140318884004160:error:140E6118:SSL routines:SSL_CIPHER_PROCESS_RULESTR:invalid command:ssl_ciph.c:1381: 140318884004160:error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers:ssl_lib.c:1983: 140318884004160:error:140E6118:SSL routines:SSL_CIPHER_PROCESS_RULESTR:invalid command:ssl_ciph.c:1381: 140318884004160:error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers:ssl_lib.c:1983: make: *** [Makefile:308: test_ssl] Error 1 """ whereas the build is successful locally on my machine: """ ../util/shlib_wrap.sh ./ssltest -test_cipherlist testing SSLv3 cipher list order: ok testing TLSv1 cipher list order: ok Testing cipherlist order only. Ignoring all other options. test sslv2 Testing was requested for a disabled protocol. Skipping tests. test sslv2 with server authentication Testing was requested for a disabled protocol. Skipping tests. test sslv2 with client authentication Testing was requested for a disabled protocol. Skipping tests. test sslv2 with both client and server authentication Testing was requested for a disabled protocol. Skipping tests. test sslv3 Available compression methods: NONE SSLv3, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA 1 handshakes of 256 bytes done """ I suspect the line: "WARNING: can't open config file: /etc/pki/tls/openssl.cnf" is caused by chroot and may be the cause of the error but I do not know how to solve the problem.
BuildRequires: openssl Should fix that
Sadly it did not solve the build issue and created a new one with Cauldron.
Weird, it used to build and we haven't changed anything. Maybe it doesn't like openssl 1.1.x's openssl.cnf any more. I've changed it to use its own openssl.cnf for the tests.
OK at least we get the same error on mga7 and mga8 now. Maybe it's something in crypto-policies that it doesn't like. I'm thinking that it's finding no enabled ciphers for sslv3 because sslv3 is mostly disabled because it's old and insecure and failing there. I don't see an obvious way to get it to skip sslv3, so maybe just patch tests/Makefile to skip evp_extra_test completely (or just disable %check).
We really do need to drop this package in Cauldron before the Mageia 8 release.
OpenSSL has issued an advisory on December 8: https://www.openssl.org/news/secadv/20201208.txt The fix for 1.0.2 is here: https://github.com/openssl/openssl/commit/2154ab83e14ede338d2ede9bbe5cdfce5d5a6c9e 1.1.x is in Bug 27791.
Summary: compat-openssl10 new security issue CVE-2020-1968 => compat-openssl10 new security issues CVE-2020-1968 and CVE-2020-1971
Severity: normal => critical
(In reply to David Walser from comment #10) > OpenSSL has issued an advisory on December 8: > https://www.openssl.org/news/secadv/20201208.txt > > The fix for 1.0.2 is here: > https://github.com/openssl/openssl/commit/ > 2154ab83e14ede338d2ede9bbe5cdfce5d5a6c9e > > 1.1.x is in Bug 27791. Debian and Ubuntu have issued an advisory for this on December 8: https://www.debian.org/security/2020/dsa-4807 https://ubuntu.com/security/notices/USN-4662-1
Suggested advisory: ======================== The updated packages fix security vulnerabilities: 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. (CVE-2020-1968) The X.509 GeneralName type is a generic type for representing different types of names. One of those name types is known as EDIPartyName. OpenSSL provides a function GENERAL_NAME_cmp which compares different instances of a GENERAL_NAME to see if they are equal or not. This function behaves incorrectly when both GENERAL_NAMEs contain an EDIPARTYNAME. A NULL pointer dereference and a crash may occur leading to a possible denial of service attack. OpenSSL itself uses the GENERAL_NAME_cmp function for two purposes: 1) Comparing CRL distribution point names between an available CRL and a CRL distribution point embedded in an X509 certificate 2) When verifying that a timestamp response token signer matches the timestamp authority name (exposed via the API functions TS_RESP_verify_response and TS_RESP_verify_token) If an attacker can control both items being compared then that attacker could trigger a crash. For example if the attacker can trick a client or server into checking a malicious certificate against a malicious CRL then this may occur. Note that some applications automatically download CRLs based on a URL embedded in a certificate. This checking happens prior to the signatures on the certificate and CRL being verified. OpenSSL's s_server, s_client and verify tools have support for the "-crl_download" option which implements automatic CRL downloading and this attack has been demonstrated to work against those tools. Note that an unrelated bug means that affected versions of OpenSSL cannot parse or construct correct encodings of EDIPARTYNAME. However it is possible to construct a malformed EDIPARTYNAME that OpenSSL's parser will accept and hence trigger this attack. (CVE-2020-1971) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1968 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1971 https://www.openssl.org/news/secadv/20200909.txt https://ubuntu.com/security/notices/USN-4504-1 https://www.openssl.org/news/secadv/20201208.txt https://www.debian.org/security/2020/dsa-4807 https://ubuntu.com/security/notices/USN-4662-1 ======================== Updated packages in core/updates_testing: ======================== compat-openssl10-1.0.2u-1.1.mga7 lib(64)compat-openssl10_1.0.0-1.0.2u-1.1.mga7 lib(64)compat-openssl10-devel-1.0.2u-1.1.mga7 from SRPM: compat-openssl10-1.0.2u-1.1.mga7.src.rpm
Status: NEW => ASSIGNEDCVE: (none) => CVE-2020-1968, CVE-2020-1971Assignee: nicolas.salguero => qa-bugsSource RPM: compat-openssl10-1.0.2r-1.mga7.src.rpm => compat-openssl10-1.0.2u-1.mga7.src.rpm
Installed and tested without issues. Tested using the sslscan package that uses the libs in the updated package. System: Mageia 7, x86_64, Intel CPU. $ rpm -q lib64compat-openssl10_1.0.0 lib64compat-openssl10_1.0.0-1.0.2u-1.1.mga7 $ rpm -ql lib64compat-openssl10_1.0.0 | egrep lib.*so /usr/lib64/libcrypto.so.1.0.0 /usr/lib64/libssl.so.1.0.0 $ strace -o /tmp/strace.log sslscan example.com Version: 1.11.13 OpenSSL 1.0.2u 20 Dec 2019 OpenSSL version does not support SSLv2 SSLv2 ciphers will not be detected Connected to 2606:2800:220:1:248:1893:25c8:1946 Testing SSL server example.com on port 443 using SNI name example.com TLS Fallback SCSV: ERROR: Could not create CTX object. TLS renegotiation: ERROR: Could not create CTX object. Session renegotiation not supported TLS Compression: ERROR: Could not create CTX object. Heartbleed: TLS 1.2 not vulnerable to heartbleed TLS 1.1 not vulnerable to heartbleed TLS 1.0 not vulnerable to heartbleed Supported Server Cipher(s): ERROR: Could not create CTX object. $ egrep 'lib64/(libcrypto.so.1.0.0|libssl.so.1.0.0)' /tmp/strace.log | sort openat(AT_FDCWD, "/lib64/libcrypto.so.1.0.0", O_RDONLY|O_CLOEXEC) = 3 openat(AT_FDCWD, "/lib64/libssl.so.1.0.0", O_RDONLY|O_CLOEXEC) = 3
CC: (none) => mageia
This update has been installed on this workstation for over a week without issues. Giving it the OK for x86_64 to see if this moves forward since it is a security update.
Whiteboard: (none) => MGA7-64-OK
Validating. Advisory in Comment 12.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
Advisory pushed to SVN.
Keywords: (none) => advisoryCC: (none) => ouaurelien
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2020-0465.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED