-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
OpenSSL Security Advisory [31st July 2023] ==========================================
Excessive time spent checking DH q parameter value (CVE-2023-3817) ==================================================================
Severity: Low
Issue summary: Checking excessively long DH keys or parameters may be very slow.
Impact summary: Applications that use the functions DHcheck(), DHcheckex() or EVPPKEYparamcheck() to check a DH key or DH parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service.
The function DHcheck() performs various checks on DH parameters. After fixing CVE-2023-3446 it was discovered that a large q parameter value can also trigger an overly long computation during some of these checks. A correct q value, if present, cannot be larger than the modulus p parameter, thus it is unnecessary to perform these checks if q is larger than p.
An application that calls DHcheck() and supplies a key or parameters obtained from an untrusted source could be vulnerable to a Denial of Service attack.
The function DHcheck() is itself called by a number of other OpenSSL functions. An application calling any of those other functions may similarly be affected. The other functions affected by this are DHcheckex() and EVPPKEYparamcheck().
Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications when using the "-check" option.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.
OpenSSL 3.1, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.
Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit 6a1eb62c2 (for 3.1), commit 9002fd073 (for 3.0) and commit 91ddeba0f (for 1.1.1) in the OpenSSL git repository. It is available to premium support customer in commit 869ad69a (for 1.0.2).
This issue was reported on 20th July 2023 by Bernd Edlinger. The fix was developed by Tomas Mraz.
General Advisory Notes ======================
URL for this Security Advisory: https://www.openssl.org/news/secadv/20230731.txt
Note: the online version of the advisory may be updated with additional details over time.
For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html
OpenSSL 1.1.1 will reach end-of-life on 2023-09-11. After that date security fixes for 1.1.1 will only be available to premium support customers. -----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmTH1M4ACgkQ2cTSbQ5g RJGhtAf9E3HklBKezKOXvAbsPmCqcjySMVTV/JrBjrDn14UIRjZmhVoHd5QGusN2 ReRtA3bRL41UQYdLKDkdYjp9XmlDDFb5hKO3G7P0ldtDaw21TkIQeI/90OKjgsQu A+vpf/TcE1a1Pbz8cIRKYBjIaS3z9yIDW4eB0gytWxsqMxze+9IOYNuAbDa0KsqO PFTUiHr5xu01wsdVdHeUMpZ01E8tGbVwgyY7tvCUAUJcjjLcTb9+gXQLn6cmVRJt 6kU8jsamkiYpL1MoKI5yQvYx0nXZUxXbH1ICPltytC4pBsMEypCCnJTkcJKhRRNt 76Z4/x3XDqMzapYMPimIRifdzPV9FQ== =Ve/V -----END PGP SIGNATURE-----
An OOB read flaw was found in the RFC 3161 Public Key Infrastructure Time-Stamp Protocol code of OpenSSL. An attacker could use this flaw to cause the openssl binary to crash when specially-crafted time-stamp file is parsed via the "openssl ts" command.
Upstream commit:
master: https://github.com/openssl/openssl/commit/0ed26acce328ec16a3aa635f1ca37365e8c7403a 1.0.1: https://github.com/openssl/openssl/commit/6adf409c7432b90c06d9890787fe56c48f2a16e7
A flaw was found in the way the DES/3DES cipher was used as part of the TLS/SSL protocol. A man-in-the-middle attacker could use this flaw to recover some plaintext data by capturing large amounts of encrypted traffic between TLS/SSL server and client if the communication used a DES/3DES based ciphersuite.
OpenSSL could allow a remote attacker to obtain sensitive information, caused by an overflow bug in the AVX2 Montgomery multiplication procedure used in exponentiation with 1024-bit moduli. An attacker could exploit this vulnerability to obtain information about the private key.
Note: In order to exploit this vulnerability, the server would have to share the DH1024 private key among multiple clients, which is no longer an option since CVE-2016-0701.
OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state" mechanism. The intent was that if a fatal error occurred during a handshake then OpenSSL would move into the error state and would immediately fail if you attempted to continue the handshake. This works as designed for the explicit handshake functions (SSLdohandshake(), SSLaccept() and SSLconnect()), however due to a bug it does not work correctly if SSLread() or SSLwrite() is called directly. In that scenario, if the handshake fails then a fatal error will be returned in the initial function call. If SSLread()/SSLwrite() is subsequently called by the application for the same SSL object then it will succeed and the data is passed without being decrypted/encrypted directly from the SSL/TLS record layer.
In order to exploit this issue an application bug would have to be present that resulted in a call to SSLread()/SSLwrite() being issued after having already received a fatal error.
External References:
https://www.openssl.org/news/secadv/20171207.txt
If an X.509 certificate has a malformed IPAddressFamily extension, OpenSSL could do a one-byte buffer overread. The most likely result would be an erroneous display of the certificate in text format.
External References:
https://www.openssl.org/news/secadv/20170828.txt
References:
https://github.com/openssl/openssl/pull/4276
Last updated 24 July 2024
If an SSL/TLS server or client is running on a 32-bit host, and a specific cipher is being used, then a truncated packet can cause that server or client to perform an out-of-bounds read, usually resulting in a crash.
For Openssl 1.0.2, the crash can be triggered when using RC4-MD5; users who have not disabled that algorithm should update to 1.0.2k
External References:
https://www.openssl.org/news/secadv/20170126.txt
A memory leak flaw was found in the way OpenSSL handled TLS status request extension data during session renegotiation. A remote attacker could cause a TLS server using OpenSSL to consume an excessive amount of memory and, possibly, exit unexpectedly after exhausting all available memory, if it enabled OCSP stapling support.
Last updated 24 July 2024
It was discovered that the Datagram TLS (DTLS) implementation could fail to release memory in certain cases. A malicious DTLS client could cause a DTLS server using OpenSSL to consume an excessive amount of memory and, possibly, exit unexpectedly after exhausting all available memory.
An integer underflow flaw leading to a buffer over-read was found in the way OpenSSL parsed TLS session tickets. A remote attacker could use this flaw to crash a TLS server using OpenSSL if it used SHA-512 as HMAC for session tickets.
A flaw was found in the Datagram TLS (DTLS) replay protection implementation in OpenSSL. A remote attacker could possibly use this flaw to make a DTLS server using OpenSSL to reject further packets sent from a DTLS client over an established DTLS connection.
It was discovered that OpenSSL did not always use constant time operations when computing Digital Signature Algorithm (DSA) signatures. A local attacker could possibly use this flaw to obtain a private DSA key belonging to another user or service running on the same system.
A common idiom in the codebase is:
if (p + len > limit) { return; / Too long / }
where p points to some malloc'd data of SIZE bytes and limit == p + SIZE. 'len' could be from some externally supplied data, e.g. TLS message. This idiom is vulnerable to integer overflow vulnerability.
An out of bounds write flaw was discovered in the OpenSSL BNbn2dec() function. An attacker able to make an application using OpenSSL to process a large BIGNUM could cause the application to crash or, possibly, execute arbitrary code.
As per Upstream advisory:
A double free bug was discovered when OpenSSL parses malformed DSA private keys and could lead to a DoS attack or memory corruption for applications that receive DSA private keys from untrusted sources. This scenario is considered rare.
This issue affects OpenSSL versions 1.0.2 and 1.0.1.
OpenSSL 1.0.2 users should upgrade to 1.0.2g OpenSSL 1.0.1 users should upgrade to 1.0.1s
This issue was reported to OpenSSL on 7th February 2016 by Adam Langley (Google/BoringSSL) using libFuzzer. The fix was developed by Dr Stephen Henson of OpenSSL.