From: Matt Caswell Date: Tue, 26 Apr 2022 13:39:34 +0000 (+0100) Subject: Update CHANGES and NEWS for new release X-Git-Tag: openssl-3.0.3~4 X-Git-Url: https://git.openssl.org/?p=openssl.git;a=commitdiff_plain;h=ffbb106a174a8bc698f41db9a07544963c01e830 Update CHANGES and NEWS for new release Reviewed-by: Tomas Mraz Release: yes --- diff --git a/CHANGES.md b/CHANGES.md index 7c3b341358..e456ed44ff 100644 --- a/CHANGES.md +++ b/CHANGES.md @@ -30,6 +30,105 @@ breaking changes, and mappings for the large list of deprecated functions. ### Changes between 3.0.2 and 3.0.3 [xx XXX xxxx] + * Fixed a bug in the c_rehash script which was not properly sanitising shell + metacharacters to prevent command injection. This script is distributed by + some operating systems in a manner where it is automatically executed. On + such operating systems, an attacker could execute arbitrary commands with the + privileges of the script. + + Use of the c_rehash script is considered obsolete and should be replaced + by the OpenSSL rehash command line tool. + (CVE-2022-1292) + + *Tomáš Mráz* + + * Fixed a bug in the function `OCSP_basic_verify` that verifies the signer + certificate on an OCSP response. The bug caused the function in the case + where the (non-default) flag OCSP_NOCHECKS is used to return a postivie + response (meaning a successful verification) even in the case where the + response signing certificate fails to verify. + + It is anticipated that most users of `OCSP_basic_verify` will not use the + OCSP_NOCHECKS flag. In this case the `OCSP_basic_verify` function will return + a negative value (indicating a fatal error) in the case of a certificate + verification failure. The normal expected return value in this case would be + 0. + + This issue also impacts the command line OpenSSL "ocsp" application. When + verifying an ocsp response with the "-no_cert_checks" option the command line + application will report that the verification is successful even though it + has in fact failed. In this case the incorrect successful response will also + be accompanied by error messages showing the failure and contradicting the + apparently successful result. + ([CVE-2022-1343]) + + *Matt Caswell* + + * Fixed a bug where the RC4-MD5 ciphersuite incorrectly used the + AAD data as the MAC key. This made the MAC key trivially predictable. + + An attacker could exploit this issue by performing a man-in-the-middle attack + to modify data being sent from one endpoint to an OpenSSL 3.0 recipient such + that the modified data would still pass the MAC integrity check. + + Note that data sent from an OpenSSL 3.0 endpoint to a non-OpenSSL 3.0 + endpoint will always be rejected by the recipient and the connection will + fail at that point. Many application protocols require data to be sent from + the client to the server first. Therefore, in such a case, only an OpenSSL + 3.0 server would be impacted when talking to a non-OpenSSL 3.0 client. + + If both endpoints are OpenSSL 3.0 then the attacker could modify data being + sent in both directions. In this case both clients and servers could be + affected, regardless of the application protocol. + + Note that in the absence of an attacker this bug means that an OpenSSL 3.0 + endpoint communicating with a non-OpenSSL 3.0 endpoint will fail to complete + the handshake when using this ciphersuite. + + The confidentiality of data is not impacted by this issue, i.e. an attacker + cannot decrypt data that has been encrypted using this ciphersuite - they can + only modify it. + + In order for this attack to work both endpoints must legitimately negotiate + the RC4-MD5 ciphersuite. This ciphersuite is not compiled by default in + OpenSSL 3.0, and is not available within the default provider or the default + ciphersuite list. This ciphersuite will never be used if TLSv1.3 has been + negotiated. In order for an OpenSSL 3.0 endpoint to use this ciphersuite the + following must have occurred: + + 1) OpenSSL must have been compiled with the (non-default) compile time option + enable-weak-ssl-ciphers + + 2) OpenSSL must have had the legacy provider explicitly loaded (either + through application code or via configuration) + + 3) The ciphersuite must have been explicitly added to the ciphersuite list + + 4) The libssl security level must have been set to 0 (default is 1) + + 5) A version of SSL/TLS below TLSv1.3 must have been negotiated + + 6) Both endpoints must negotiate the RC4-MD5 ciphersuite in preference to any + others that both endpoints have in common + (CVE-2022-1434) + + *Matt Caswell * + + * Fix a bug in the OPENSSL_LH_flush() function that breaks reuse of the memory + occuppied by the removed hash table entries. + + This function is used when decoding certificates or keys. If a long lived + process periodically decodes certificates or keys its memory usage will + expand without bounds and the process might be terminated by the operating + system causing a denial of service. Also traversing the empty hash table + entries will take increasingly more time. + + Typically such long lived processes might be TLS clients or TLS servers + configured to accept client certificate authentication. + (CVE-2022-1473) + + *Tomáš Mráz* + * The functions `OPENSSL_LH_stats` and `OPENSSL_LH_stats_bio` now only report the `num_items`, `num_nodes` and `num_alloc_nodes` statistics. All other statistics are no longer supported. For compatibility, these statistics are diff --git a/NEWS.md b/NEWS.md index 87968cc0a4..f0fda61299 100644 --- a/NEWS.md +++ b/NEWS.md @@ -20,7 +20,14 @@ OpenSSL 3.0 ### Major changes between OpenSSL 3.0.2 and OpenSSL 3.0.3 [under development] - * none + * Fixed a bug in the c_rehash script which was not properly sanitising shell + metacharacters to prevent command injection ([CVE-2022-1292]) + * Fixed a bug in the function `OCSP_basic_verify` that verifies the signer + certificate on an OCSP response ([CVE-2022-1343]) + * Fixed a bug where the RC4-MD5 ciphersuite incorrectly used the + AAD data as the MAC key ([CVE-2022-1434]) + * Fix a bug in the OPENSSL_LH_flush() function that breaks reuse of the memory + occuppied by the removed hash table entries ([CVE-2022-1473]) ### Major changes between OpenSSL 3.0.1 and OpenSSL 3.0.2 [15 Mar 2022]