Уязвимость функций DH_check(), DH_check_ex() или EVP_PKEY_param_check() библиотеки OpenSSL, позволяющая нарушителю вызвать отказ в обслуживании

Уязвимость функций DH_check(), DH_check_ex(), EVP_PKEY_param_check() библиотеки OpenSSL, позволяющая нарушителю вызвать отказ в обслуживании

Уязвимость криптографической библиотеки OpenSSL, связанная с неправильной проверкой ввода, позволяющая нарушителю выполнить атаку типа «отказ в обслуживании»

Issue summary: Checking excessively long DH keys or parameters may be very slow.

Impact summary: Applications that use the functions DH_check(), DH_check_ex()
or EVP_PKEY_param_check() 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 DH_check() performs various checks on DH parameters. One of those
checks confirms that the modulus ('p' parameter) is not too large. Trying to use
a very large modulus is slow and OpenSSL will not normally use a modulus which
is over 10,000 bits in length.

However the DH_check() function checks numerous aspects of the key or parameters
that have been supplied. Some of those checks use the supplied modulus value
even if it has already been found to be too large.

An application that calls DH_check() and supplies a key or parameters obtained
from an untrusted source could be vulernable to a Denial of Service attack.

The function DH_check() 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 DH_check_ex() and
EVP_PKEY_param_check().

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.

Issue summary: Checking excessively long DH keys or parameters may be very slow.

Impact summary: Applications that use the functions DH_check(), DH_check_ex()
or EVP_PKEY_param_check() 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 DH_check() 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 DH_check() and supplies a key or parameters obtained
from an untrusted source could be vulnerable to a Denial of Service attack.

The function DH_check() 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 DH_check_ex() and
EVP_PKEY_param_check().

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.

Issue summary: The POLY1305 MAC (message authentication code) implementation
contains a bug that might corrupt the internal state of applications on the
Windows 64 platform when running on newer X86_64 processors supporting the
AVX512-IFMA instructions.

Impact summary: If in an application that uses the OpenSSL library an attacker
can influence whether the POLY1305 MAC algorithm is used, the application
state might be corrupted with various application dependent consequences.

The POLY1305 MAC (message authentication code) implementation in OpenSSL does
not save the contents of non-volatile XMM registers on Windows 64 platform
when calculating the MAC of data larger than 64 bytes. Before returning to
the caller all the XMM registers are set to zero rather than restoring their
previous content. The vulnerable code is used only on newer x86_64 processors
supporting the AVX512-IFMA instructions.

The consequences of this kind of internal application state corruption can
be various - from no consequences, if the calling application does not
depend on the contents of non-volatile XMM registers at all, to the worst
consequences, where the attacker could get complete control of the application
process. However given the contents of the registers are just zeroized so
the attacker cannot put arbitrary values inside, the most likely consequence,
if any, would be an incorrect result of some application dependent
calculations or a crash leading to a denial of service.

The POLY1305 MAC algorithm is most frequently used as part of the
CHACHA20-POLY1305 AEAD (authenticated encryption with associated data)
algorithm. The most common usage of this AEAD cipher is with TLS protocol
versions 1.2 and 1.3 and a malicious client can influence whether this AEAD
cipher is used by the server. This implies that server applications using
OpenSSL can be potentially impacted. However we are currently not aware of
any concrete application that would be affected by this issue therefore we
consider this a Low severity security issue.

As a workaround the AVX512-IFMA instructions support can be disabled at
runtime by setting the environment variable OPENSSL_ia32cap:

   OPENSSL_ia32cap=:~0x200000

The FIPS provider is not affected by this issue.