Where
AND
-Infinity
0
Severity
5.3
EPSS
0.13%
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

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

1 / 7
Source: Red Hat
First published (updated )
Severity
7.5
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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

1 / 4
Source: Red Hat
First published (updated )
Severity
7.5
Infoleak, Weak Encryption
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

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.

1 / 5

Remedy

1.SSL/TLS configurations should prefer AES over DES. Versions of OpenSSL shipped with Red Hat Enterprise Linux 6 and 7 already do so. In the version of OpenSSL shipped with Red Hat Enterprise Linux 5, 3DES is listed below the AES-256 cipher and above the AES-128 cipher, therefore AES-256 based ciphersuite should not be disabled on the server. 2. Servers using OpenSSL, should not disable AES-128 and AES-256 ciphersuites. Versions of Apache shipped with Red Hat Enterprise Linux use the default cipher string, in which AES is preferred over DES/3DES based ciphersuites. For JBoss Middleware, and Java mitigations, please review this knowledge base article: https://access.redhat.com/articles/2598471 This can be mitigated on OpenShift Container Platform (OCP) by disabling the vulnerable TLS cipher suite in the applicable component. TLS configuration options for OCP are described here: https://access.redhat.com/articles/5348961
First published (updated )
Severity
5.9
Infoleak
AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N

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.

1 / 3
Source: IBM
First published (updated )
Severity
5.9
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

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

1 / 3
Source: Red Hat
First published (updated )
Severity
5.3
Buffer Overflow
AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N

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

1 / 5
Source: Red Hat
First published (updated )
Severity
5.9
Infoleak
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

Last updated 24 July 2024

1 / 3
Source: Ubuntu
First published (updated )
Severity
7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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

1 / 3
Source: Red Hat
First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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.

1 / 4
First published (updated )
Severity
5.9
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Last updated 24 July 2024

1 / 4
Source: Ubuntu
First published (updated )
Severity
7.5
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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.

1 / 5
First published (updated )
Severity
7.5
Input Validation, Integer Overflow
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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.

1 / 4
First published (updated )
Severity
7.5
Input Validation
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

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.

1 / 5
First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

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.

1 / 4
First published (updated )
Severity
9.8
Integer Overflow
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

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.

1 / 4
Source: Red Hat
First published (updated )
Severity
9.8
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

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.

1 / 4
First published (updated )
Severity
9.8
Double Free
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

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.

1 / 2
Source: Red Hat
First published (updated )
Severity
5
AV:N/AC:L/Au:N/C:N/I:N/A:P

The ssl3getkeyexchange function in ssl/s3clnt.c in OpenSSL 1.0.2 before 1.0.2e allows remote servers to cause a denial of service (segmentation fault) via a zero p value in an anonymous Diffie-Hellman (DH) ServerKeyExchange message.

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203