David Benjamin

The issue is related to a denial of service in X.509 name checks. Applications performing certificate name checks, such as TLS clients checking server certificates, may attempt to read an invalid memory address when comparing the expected name with an `otherName` subject alternative name of an X.509 certificate. This may result in an exception that terminates the application program. Basic certificate chain validation is not affected, and the denial of service can occur only when the application also specifies an expected DNS name, Email address, or IP address. TLS servers are generally not affected, and the severity of the issue is Moderate.

The issue is related to the OpenSSL API function `SSL select next proto` which can cause a crash or memory contents to be sent to the peer when called with an empty supported client protocols buffer. This can result in a loss of confidentiality, with up to 255 bytes of arbitrary private data from memory being sent to the peer. The issue is typically not under attacker control and may occur by accident due to a configuration or programming error in the calling application. The `SSL select next proto` function is used by TLS applications that support ALPN (Application Layer Protocol Negotiation) or NPN (Next Protocol Negotiation), with NPN being older and deprecated in favor of 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.

The issue is related to the GENERAL NAME cmp function in OpenSSL, which compares different instances of a GENERAL NAME to see if they are equal or not. This function behaves incorrectly when both GENERAL NAMEs contain an EDIPARTYNAME, leading to a NULL pointer dereference and a crash, which may result in a denial of service attack. The GENERAL NAME cmp function is used for comparing CRL distribution point names and verifying timestamp response token signers. An attacker could trigger a crash by controlling both items being compared, for example, by tricking a client or server into checking a malicious certificate against a malicious CRL. Some applications automatically download CRLs based on a URL embedded in a certificate, which may also lead to this issue.

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.