Ben Smyth

**Nome do Software Vulnerável e Versões Afetadas** OCaml-TLS versões anteriores a 2.1.0 **Descrição** A implementação do cliente no OCaml-TLS não valida adequadamente as extensões KeyUsage e ExtendedKeyUsage (EKU) dos certificados do servidor durante handshakes TLS 1.3. Especificamente, a função `answer certificate` em `handshake client13.ml` não está vinculada à função `validate keyusage()`, que é responsável por verificar a `Server auth` (OID 1.3.6.1.5.5.7.3.1). Isso permite que um invasor que possua um certificado emitido para finalidades diferentes da autenticação de servidor—como `clientAuth`, `codeSigning` ou `emailProtection`—se passe por um servidor, desde que o certificado seja emitido por uma CA confiável e o Subject Alternative Name (SAN) corresponda ao nome do host de destino. **Recomendações** Atualize o OCaml-TLS para a versão 2.1.0.

**Nome do Software Vulnerável e Versões Afetadas** OCaml-TLS versões anteriores a 2.1.0 **Description** A implementação do servidor não valida adequadamente as extensões `KeyUsage` e `ExtendedKeyUsage` dos certificados fornecidos por clientes durante a autenticação TLS mútua (mTLS). Isso permite que um invasor se passe por um cliente usando um certificado que foi destinado apenas para autenticação de servidor (contendo `id-kp-serverAuth`). Especificamente, a biblioteca não verifica se o certificado inclui `digitalSignature` em seu `keyUsage` ou `clientAuth` em seu `ExtendedKeyUsage`. Detalhes técnicos indicam que o problema ocorre na função `validateCerts()` em `handshake server.ml` e na função `answerClientCertificate()` em `handshake server13.ml`, onde o processo `validateChain` é concluído sem verificar essas restrições específicas. Isso pode levar ao acesso não autorizado se o servidor confiar em uma Autoridade Certificadora (CA) que emite certificados apenas para servidor, como uma CA corporativa interna ou um repositório de confiança PKI público. **Recommendations** Atualize para a versão 2.1.0. Como solução temporária, restrinja o repositório de confiança para incluir apenas CAs que separem estritamente certificados de cliente e servidor, ou implemente um controle de pós-validação baseado em Common Name (CN) ou Subject Alternative Name (SAN) para verificar a identidade do cliente autenticado.

Name of the Vulnerable Software and Affected Versions Botan versões anteriores a 3.11.1 Description A implementação TLS 1.3 no Botan permitia o processamento de registros ApplicationData antes que a mensagem Finished fosse recebida. Isso poderia permitir que um cliente ignorasse a autenticação de cliente imposta pelo servidor via certificados, omitindo as mensagens Certificate, CertificateVerify e Finished e, em vez disso, enviando registros de dados de aplicativo. Recommendations Atualize para a versão 3.11.1 ou posterior.

**Name of the Vulnerable Software and Affected Versions** Node.js (affected versions not specified) **Description** The generateKeys() API function returned from crypto.createDiffieHellman() only generates missing (or outdated) keys, that is, it only generates a private key if none has been set yet, but the function is also needed to compute the corresponding public key after calling setPrivateKey(). However, the documentation says this API call: "Generates private and public Diffie-Hellman key values". The documented behavior is very different from the actual behavior, and this difference could easily lead to security issues in applications that use these APIs as the DiffieHellman may be used as the basis for application-level security, implications are consequently broad. **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** Oracle Java SE versions 8u361, 8u361-perf, 11.0.18, 17.0.6, 20 Oracle GraalVM Enterprise Edition versions 20.3.9, 21.3.5, 22.3.1 **Description** The vulnerability is related to the JSSE component of Oracle Java SE and Oracle GraalVM Enterprise Edition, allowing an unauthenticated attacker with network access via TLS to compromise the system. Successful attacks can result in unauthorized creation, deletion, or modification of access to critical data. This issue applies to Java deployments that load and run untrusted code and rely on the Java sandbox for security. It can also be exploited through APIs in the specified component. **Recommendations** For Oracle Java SE versions 8u361, 8u361-perf, 11.0.18, 17.0.6, 20: Update to a fixed version to resolve the issue. For Oracle GraalVM Enterprise Edition versions 20.3.9, 21.3.5, 22.3.1: Update to a fixed version to resolve the issue. As a temporary workaround, consider restricting access to the JSSE component until a patch is available. Avoid using APIs in the specified component, e.g., through a web service, until the issue is resolved.