Tomas Mraz

A timing side-channel exists in the SM2 algorithm implementation on 64-bit ARM platforms. This issue could potentially allow a remote attacker to recover the private key through precise timing measurements. While remote key recovery over a network has not been demonstrated, timing measurements have revealed a timing signal that may enable such an attack. The vulnerability is considered a moderate severity issue, particularly in scenarios where support for SM2 certificates is added via a custom provider. The FIPS modules in OpenSSL versions 3.0, 3.1, 3.2, 3.3, 3.4, and 3.5 are not affected, as SM2 is not an approved algorithm.

The issue is related to the functions `EVP PKEY param check()` and `EVP PKEY public check()` in the OpenSSL library, which can lead to a Denial of Service (DoS) attack when checking excessively long DSA keys or parameters. These functions perform various checks on DSA parameters, and some computations can take a long time if the modulus (`p` parameter) is too large. An application that calls these functions and supplies a key or parameters obtained from an untrusted source could be vulnerable to a DoS attack. The OpenSSL SSL/TLS implementation is not affected by this issue.

The issue is related to the function `EVP PKEY public check()` in the OpenSSL library, which can lead to a Denial of Service (DoS) attack when checking excessively long invalid RSA public keys. This can cause long delays in applications that use this function to check RSA public keys obtained from untrusted sources. The `EVP PKEY public check()` function is called from the OpenSSL pkey command line application, making it vulnerable when used with the '-pubin' and '-check' options on untrusted data. The OpenSSL SSL/TLS implementation is not affected by this issue.

The issue is related to the functions `DH check()`, `DH check ex()`, and `EVP PKEY param check()` in the OpenSSL library. These functions can cause excessive delays when checking excessively long DH keys or parameters, potentially leading to a Denial of Service attack if the key or parameters are obtained from an untrusted source. The `DH check()` function performs various checks on DH parameters, and a large `q` parameter value can trigger an overly long computation during some of these checks. The OpenSSL SSL/TLS implementation and the OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.

The issue is related to the functions `DH check()`, `DH check ex()`, and `EVP PKEY param check()` in the OpenSSL library. These functions can cause long delays when checking excessively long DH keys or parameters, potentially leading to a Denial of Service (DoS) attack if the key or parameters are obtained from an untrusted source. The `DH check()` function performs various checks on DH parameters, including confirming that the modulus (`p` parameter) is not too large. However, trying to use a very large modulus is slow, and OpenSSL will not normally use a modulus over 10,000 bits in length. The OpenSSL SSL/TLS implementation and the OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.

The AES-SIV cipher implementation in OpenSSL contains a bug that causes it to ignore empty associated data entries, which are unauthenticated as a consequence. This issue can mislead applications that use the AES-SIV algorithm and want to authenticate empty data entries as associated data by removing, adding, or reordering such empty entries. The AES-SIV algorithm allows for authentication of multiple associated data entries along with the encryption. To authenticate empty data, the application has to call `EVP EncryptUpdate()` (or `EVP CipherUpdate()`) with a NULL pointer as the output buffer and 0 as the input buffer length. However, the AES-SIV implementation in OpenSSL just returns success for such a call instead of performing the associated data authentication operation. The empty data thus will not be authenticated. This issue does not affect non-empty associated data authentication, and it is expected to be rare for an application to use empty associated data entries.

The function `X509 VERIFY PARAM add0 policy()` is documented to implicitly enable the certificate policy check when doing certificate verification. However, the implementation of the function does not enable the check, which allows certificates with invalid or incorrect policies to pass the certificate verification. This could potentially allow a remote attacker to execute a "man-in-the-middle" attack. Certificate policy checks are disabled by default in OpenSSL and are not commonly used by applications.

The issue is related to a stack-based buffer overflow in the `url::get pac` function, which can be triggered by a large proxy.pac file from remote servers. This may lead to unspecified consequences. The vulnerability can be exploited remotely and may result in a breach of confidentiality, integrity, and availability of protected information.

The issue concerns multiple vulnerabilities in the pam package of Red Hat Enterprise Linux. These vulnerabilities can be exploited locally, potentially leading to breaches of confidentiality, integrity, and availability of protected information. The pam namespace module in Linux-PAM is specifically affected, where it uses the environment of the invoking application or service during execution of the namespace.init script. This might allow local users to gain privileges by running a setuid program that relies on the pam namespace PAM check.

Name of the Vulnerable Software and Affected Versions: OpenSSH version 4.3p2 Description: The issue allows remote attackers to write arbitrary characters to an audit log via a crafted `username`. This is due to an unspecified vulnerability in the `linux audit record event` function. Recommendations: For OpenSSH version 4.3p2, at the moment, there is no information about a newer version that contains a fix for this vulnerability.