CVSS: 5.9EPSS: 0%CPEs: 3EXPL: 0CVE-2023-6237 – Excessive time spent checking invalid RSA public keys
https://notcve.org/view.php?id=CVE-2023-6237
Issue summary: Checking excessively long invalid RSA public keys may take a long time. Impact summary: Applications that use the function EVP_PKEY_public_check() to check RSA public keys may experience long delays. Where the key that is being checked has been obtained from an untrusted source this may lead to a Denial of Service. When function EVP_PKEY_public_check() is called on RSA public keys, a computation is done to confirm that the RSA modulus, n, is composite. For valid RSA keys, n is a product of two or more large primes and this computation completes quickly. However, if n is an overly large prime, then this computation would take a long time. An application that calls EVP_PKEY_public_check() and supplies an RSA key obtained from an untrusted source could be vulnerable to a Denial of Service attack. The function EVP_PKEY_public_check() is not called from other OpenSSL functions however it is called from the OpenSSL pkey command line application. For that reason that application is also vulnerable if used with the '-pubin' and '-check' options on untrusted data. The OpenSSL SSL/TLS implementation is not affected by this issue. The OpenSSL 3.0 and 3.1 FIPS providers are affected by this issue. Resumen del problema: la comprobación de claves públicas RSA inválidas excesivamente largas puede llevar mucho tiempo. • http://www.openwall.com/lists/oss-security/2024/03/11/1 https://github.com/openssl/openssl/commit/0b0f7abfb37350794a4b8960fafc292cd5d1b84d https://github.com/openssl/openssl/commit/18c02492138d1eb8b6548cb26e7b625fb2414a2a https://github.com/openssl/openssl/commit/a830f551557d3d66a84bbb18a5b889c640c36294 https://security.netapp.com/advisory/ntap-20240531-0007 https://www.openssl.org/news/secadv/20240115.txt https://access.redhat.com/security/cve/CVE-2023-6237 https://bugzilla.redhat.com/show_bug.cgi?id=2258502 • CWE-400: Uncontrolled Resource Consumption •
CVSS: 6.5EPSS: 0%CPEs: 3EXPL: 0CVE-2023-6129 – POLY1305 MAC implementation corrupts vector registers on PowerPC
https://notcve.org/view.php?id=CVE-2023-6129
Issue summary: The POLY1305 MAC (message authentication code) implementation contains a bug that might corrupt the internal state of applications running on PowerPC CPU based platforms if the CPU provides vector instructions. Impact summary: If 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 for PowerPC CPUs restores the contents of vector registers in a different order than they are saved. Thus the contents of some of these vector registers are corrupted when returning to the caller. The vulnerable code is used only on newer PowerPC processors supporting the PowerISA 2.07 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 unless the compiler uses the vector registers for storing pointers, 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. • http://www.openwall.com/lists/oss-security/2024/03/11/1 https://github.com/openssl/openssl/commit/050d26383d4e264966fb83428e72d5d48f402d35 https://github.com/openssl/openssl/commit/5b139f95c9a47a55a0c54100f3837b1eee942b04 https://github.com/openssl/openssl/commit/f3fc5808fe9ff74042d639839610d03b8fdcc015 https://security.netapp.com/advisory/ntap-20240216-0009 https://security.netapp.com/advisory/ntap-20240426-0008 https://security.netapp.com/advisory/ntap-20240426-0013 https://security.netapp.com/advisory/ntap-20240503-0011 https: • CWE-328: Use of Weak Hash CWE-787: Out-of-bounds Write •
CVSS: 5.3EPSS: 0%CPEs: 4EXPL: 0CVE-2023-5678 – Excessive time spent in DH check / generation with large Q parameter value
https://notcve.org/view.php?id=CVE-2023-5678
Issue summary: Generating excessively long X9.42 DH keys or checking excessively long X9.42 DH keys or parameters may be very slow. Impact summary: Applications that use the functions DH_generate_key() to generate an X9.42 DH key may experience long delays. Likewise, applications that use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check() to check an X9.42 DH key or X9.42 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. While DH_check() performs all the necessary checks (as of CVE-2023-3817), DH_check_pub_key() doesn't make any of these checks, and is therefore vulnerable for excessively large P and Q parameters. Likewise, while DH_generate_key() performs a check for an excessively large P, it doesn't check for an excessively large Q. An application that calls DH_generate_key() or DH_check_pub_key() and supplies a key or parameters obtained from an untrusted source could be vulnerable to a Denial of Service attack. DH_generate_key() and DH_check_pub_key() are also 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_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate(). Also vulnerable are the OpenSSL pkey command line application when using the "-pubcheck" option, as well as the OpenSSL genpkey command line application. 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. Resumen del problema: generar claves X9.42 DH excesivamente largas o comprobar claves o parámetros X9.42 DH excesivamente largos puede ser muy lento. • http://www.openwall.com/lists/oss-security/2024/03/11/1 https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=34efaef6c103d636ab507a0cc34dca4d3aecc055 https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=710fee740904b6290fef0dd5536fbcedbc38ff0c https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=db925ae2e65d0d925adef429afc37f75bd1c2017 https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=ddeb4b6c6d527e54ce9a99cba785c0f7776e54b6 https://security.netapp.com/advisory/ntap-20231130-0010 https:/ • CWE-325: Missing Cryptographic Step CWE-754: Improper Check for Unusual or Exceptional Conditions •
CVSS: 7.5EPSS: 0%CPEs: 13EXPL: 0CVE-2023-5363 – Incorrect cipher key & IV length processing
https://notcve.org/view.php?id=CVE-2023-5363
Issue summary: A bug has been identified in the processing of key and initialisation vector (IV) lengths. This can lead to potential truncation or overruns during the initialisation of some symmetric ciphers. Impact summary: A truncation in the IV can result in non-uniqueness, which could result in loss of confidentiality for some cipher modes. When calling EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() or EVP_CipherInit_ex2() the provided OSSL_PARAM array is processed after the key and IV have been established. Any alterations to the key length, via the "keylen" parameter or the IV length, via the "ivlen" parameter, within the OSSL_PARAM array will not take effect as intended, potentially causing truncation or overreading of these values. The following ciphers and cipher modes are impacted: RC2, RC4, RC5, CCM, GCM and OCB. For the CCM, GCM and OCB cipher modes, truncation of the IV can result in loss of confidentiality. For example, when following NIST's SP 800-38D section 8.2.1 guidance for constructing a deterministic IV for AES in GCM mode, truncation of the counter portion could lead to IV reuse. Both truncations and overruns of the key and overruns of the IV will produce incorrect results and could, in some cases, trigger a memory exception. • http://www.openwall.com/lists/oss-security/2023/10/24/1 https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=0df40630850fb2740e6be6890bb905d3fc623b2d https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=5f69f5c65e483928c4b28ed16af6e5742929f1ee https://security.netapp.com/advisory/ntap-20231027-0010 https://security.netapp.com/advisory/ntap-20240201-0003 https://security.netapp.com/advisory/ntap-20240201-0004 https://www.debian.org/security/2023/dsa-5532 https://www.openssl.org/news/ • CWE-325: Missing Cryptographic Step •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2023-4807 – POLY1305 MAC implementation corrupts XMM registers on Windows
https://notcve.org/view.php?id=CVE-2023-4807
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. • https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4bfac4471f53c4f74c8d81020beb938f92d84ca5 https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=6754de4a121ec7f261b16723180df6592cbb4508 https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=a632d534c73eeb3e3db8c7540d811194ef7c79ff https://security.netapp.com/advisory/ntap-20230921-0001 https://www.openssl.org/news/secadv/20230908.txt •