David Benjamin

O problema está relacionado a uma negação de serviço nas verificações de nomes X.509. Aplicativos que realizam verificações de nomes de certificados, como clientes TLS que verificam certificados de servidor, podem tentar ler um endereço de memória inválido ao comparar o nome esperado com um nome alternativo do sujeito `otherName` de um certificado X.509. Isso pode resultar em uma exceção que encerra o programa aplicativo. A validação básica da cadeia de certificados não é afetada, e a negação de serviço só pode ocorrer quando o aplicativo também especifica um nome DNS, endereço de e-mail ou endereço IP esperado. Os servidores TLS geralmente não são afetados, e a gravidade do problema é Moderada.

O problema está relacionado à função da API do OpenSSL `SSL select next proto`, que pode causar uma falha ou o envio do conteúdo da memória para o par quando chamada com um buffer vazio de protocolos de cliente suportados. Isso pode resultar em perda de confidencialidade, com até 255 bytes de dados privados arbitrários da memória sendo enviados para o par. O problema normalmente não está sob o controle do invasor e pode ocorrer acidentalmente devido a um erro de configuração ou programação no aplicativo que faz a chamada. A função `SSL select next proto` é usada por aplicativos TLS que suportam ALPN (Application Layer Protocol Negotiation) ou NPN (Next Protocol Negotiation), sendo que o NPN é mais antigo e está obsoleto em favor do ALPN.

The issue is related to the generation and checking of excessively long X9.42 DH keys or parameters, which may cause long delays in applications using the affected functions. This can lead to a Denial of Service attack if the key or parameters are obtained from an untrusted source. The `DH generate key()` and `DH check pub key()` functions are vulnerable to excessively large P and Q parameters. Other affected functions include `DH check pub key ex()`, `EVP PKEY public check()`, and `EVP PKEY generate()`. The OpenSSL pkey command line application and the OpenSSL genpkey command line application are also vulnerable when using the "-pubcheck" option.

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 the handling of invalid certificate policies in leaf certificates by OpenSSL. When a non-default option is used for verifying certificates, applications may be vulnerable to an attack from a malicious Certificate Authority (CA) that could circumvent certain checks. Invalid certificate policies in leaf certificates are silently ignored, and other certificate policy checks are skipped for that certificate. A malicious CA could deliberately assert invalid certificate policies to circumvent policy checking on the certificate altogether. Policy processing is disabled by default but can be enabled by passing the `-policy` argument to the command line utilities or by calling the `X509 VERIFY PARAM set1 policies()` function.

A security issue has been identified in OpenSSL related to the verification of X.509 certificate chains that include policy constraints. Attackers may be able to exploit this issue by creating a malicious certificate chain that triggers exponential use of computational resources, leading to a denial-of-service (DoS) attack on affected systems. Policy processing is disabled by default but can be enabled by passing the `-policy` argument to the command line utilities or by calling the `X509 VERIFY PARAM set1 policies()` function.

A denial-of-service issue was addressed with improved input validation. Processing a maliciously crafted certificate may lead to a denial-of-service. The issue is related to uncontrolled resource consumption when processing certificates, which can be exploited by a remote attacker to cause a denial-of-service.

There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1 STRING but the public structure definition for GENERAL NAME incorrectly specified the type of the x400Address field as ASN1 TYPE. This field is subsequently interpreted by the OpenSSL function GENERAL NAME cmp as an ASN1 TYPE rather than an ASN1 STRING. When CRL checking is enabled (i.e. the application sets the X509 V FLAG CRL CHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a memcmp call, enabling them to read memory contents or enact a denial of service. In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. As such, this vulnerability is most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network.

O problema está relacionado à função GENERAL NAME cmp no OpenSSL, que compara diferentes instâncias de um GENERAL NAME para verificar se são iguais ou não. Essa função se comporta incorretamente quando ambos os GENERAL NAMEs contêm um EDIPARTYNAME, levando a uma desreferência de ponteiro NULL e a uma falha, o que pode resultar em um ataque de negação de serviço. A função GENERAL NAME cmp é usada para comparar nomes de pontos de distribuição de CRL e verificar signatários de tokens de resposta de carimbo de data/hora. Um invasor poderia provocar uma falha controlando ambos os itens que estão sendo comparados, por exemplo, induzindo um cliente ou servidor a verificar um certificado malicioso contra uma CRL maliciosa. Alguns aplicativos baixam automaticamente CRLs com base em uma URL incorporada em um certificado, o que também pode levar a esse problema.

The issue allows an unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, and JRockit. Successful attacks can result in unauthorized creation, deletion, or modification access to critical data or all accessible data, as well as unauthorized access to critical data or complete access to all accessible data. This issue can be exploited through sandboxed Java Web Start applications, sandboxed Java applets, or by supplying data to APIs in the specified component.

The issue concerns a TLS handshake failure due to the use of SSL read(), allowing an active network attacker to send application data to Node.js using the TLS or HTTP2 modules, bypassing TLS authentication and encryption.

Name of the Vulnerable Software and Affected Versions: OpenSSL versions 1.0.2b through 1.0.2m MySQL Server versions 5.6.38 and earlier MySQL Server versions 5.7.20 and earlier Description: The issue is related to the incorrect handling of the "error state" mechanism in OpenSSL when `SSL read()` or `SSL write()` functions are called directly. This can lead to the transmission of unencrypted confidential data over the network at the SSL/TLS level. The vulnerability can be exploited if an application bug results in a call to `SSL read()` or `SSL write()` after a fatal error has been received. Recommendations: For OpenSSL versions 1.0.2b through 1.0.2m, update to OpenSSL 1.0.2n to resolve the issue. For MySQL Server versions 5.6.38 and earlier, and 5.7.20 and earlier, consider restricting access to the affected MySQL Server component until a patch is available. As a temporary workaround, consider disabling the use of `SSL read()` and `SSL write()` functions directly in applications until the issue is resolved.

The issue is related to the Conscrypt component in the Android operating system and involves improper identification of session reuse. This can be exploited by a remote attacker to execute arbitrary code.

The issue is caused by a buffer overflow in the ASN.1 implementation, allowing remote attackers to execute arbitrary code or cause a denial of service via a crafted ANY field in serialized data. This can lead to memory corruption. The vulnerability is related to the misinterpretation of large universal tags as negative zero values in ANY structures.

The issue is related to multiple unspecified vulnerabilities in the code of Google Chrome, which can be exploited by remote attackers to cause a denial of service or possibly have other impact via unknown vectors. The estimated number of potentially affected devices worldwide is not available. There is no information about real-world incidents where this issue was exploited.

A double free issue allows attackers to write to arbitrary files by using a crafted app that accesses `AtomicBufferedFile` descriptors.

The issue is related to the processing of X.509 Basic Constraints cA values during the identification of alternative certificate chains, which can allow remote attackers to spoof a Certification Authority role and trigger unintended certificate verifications via a valid leaf certificate. This can enable an attacker to forge "trusted" certificates that could be used to conduct man-in-the-middle attacks. The vulnerability affects applications that verify certificates, including SSL/Transport Layer Security (TLS)/Datagram Transport Layer Security (DTLS) clients and SSL/TLS/DTLS servers using client authentication.