Tomas Mraz

**Name of the Vulnerable Software and Affected Versions** OpenSSL versions prior to 3.0.17-1~deb12u3 OpenSSL versions prior to 3.5.1-1+deb13u1 OpenSSL versions prior to 3.5.4 OpenSSL versions prior to 3.4.3 OpenSSL versions prior to 3.3.5 OpenSSL versions prior to 3.2.6 **Description** 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. **Recommendations** Upgrade OpenSSL to version 3.0.17-1~deb12u3 or later. Upgrade OpenSSL to version 3.5.1-1+deb13u1 or later. Upgrade OpenSSL to version 3.5.4 or later. Upgrade OpenSSL to version 3.4.3 or later. Upgrade OpenSSL to version 3.3.5 or later. Upgrade OpenSSL to version 3.2.6 or later.

**Name of the Vulnerable Software and Affected Versions** OpenSSL versions 3.0 and 3.1 FIPS providers **Description** 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. **Recommendations** For OpenSSL versions 3.0 and 3.1 FIPS providers, consider disabling the `EVP PKEY param check()` and `EVP PKEY public check()` functions until a patch is available. Restrict access to the `pkey` and `pkeyparam` command line applications when using the `-check` option to minimize the risk of exploitation. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** OpenSSL versions 3.0 through 3.1 **Description** 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. **Recommendations** For OpenSSL versions 3.0 through 3.1, consider disabling the `EVP PKEY public check()` function until a patch is available to prevent potential Denial of Service attacks. Restrict access to the OpenSSL pkey command line application when used with the '-pubin' and '-check' options on untrusted data to minimize the risk of exploitation. Avoid using the `EVP PKEY public check()` function on untrusted RSA public keys until the issue is resolved. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** OpenSSL versions prior to 3.0 OpenSSL versions prior to 3.1 **Description** 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. **Recommendations** For OpenSSL versions prior to 3.0, update to version 3.0 or later to resolve the issue. For OpenSSL versions prior to 3.1, update to version 3.1 or later to resolve the issue. As a temporary workaround, consider restricting the use of the `DH check()`, `DH check ex()`, and `EVP PKEY param check()` functions to minimize the risk of exploitation. Avoid using the `dhparam` and `pkeyparam` command line applications with the "-check" option until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** OpenSSL versions prior to 41.0.3 **Description** 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. **Recommendations** To resolve the issue, update to OpenSSL version 41.0.3 or later. As a temporary workaround, consider restricting the use of the `DH check()`, `DH check ex()`, and `EVP PKEY param check()` functions to minimize the risk of exploitation. Avoid using the `p` parameter with large modulus values in the affected functions until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** OpenSSL (affected versions not specified) **Description** 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. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** OpenSSL (affected versions not specified) **Description** 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. **Recommendations** To resolve the issue, applications that require OpenSSL to perform certificate policy checks need to use `X509 VERIFY PARAM set1 policies()` or explicitly enable the policy check by calling `X509 VERIFY PARAM set flags()` with the `X509 V FLAG POLICY CHECK` flag argument. As a temporary workaround, consider disabling the use of the `X509 VERIFY PARAM add0 policy()` function until a patch is available. Restrict access to the vulnerable `X509 VERIFY PARAM add0 policy()` function to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** libproxy versions 0.4.x through 0.4.9 **Description** 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. **Recommendations** For libproxy versions 0.4.x through 0.4.9, update to version 0.4.9 or later to resolve the issue. At the moment, there is no information about additional mitigation measures for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** pam versions prior to 1.1.3 Red Hat Enterprise Linux (affected versions not specified) **Description** 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. **Recommendations** For versions prior to 1.1.3, update to version 1.1.3 or later to resolve the issue. As a temporary workaround, consider restricting the use of the pam namespace module until a patch is available. Avoid using setuid programs that rely on the pam namespace PAM check in vulnerable versions.

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.