# OpenSSL Advisory: February 7th, 2023

OpenSSL have published a [security advisory](https://www.openssl.org/news/secadv/20230207.txt). Here's how it affects BoringSSL:

CVE | Summary | [Severity] in OpenSSL | Impact to BoringSSL
----|---------|-----------------------|---------------------
CVE-2023-0286 | X.400 address type confusion in X.509 GeneralName | High | Fixed in [f219ae9](https://boringssl.googlesource.com/boringssl/+/f219ae96bef5be04e78ddb5b5226ccb6439bd3ed); see discussion below.
CVE-2022-4304 | Timing Oracle in RSA Decryption | Moderate | Not affected; see discussion below.
CVE-2022-4203 | X.509 Name Constraints Read Buffer Overflow | Moderate | Not affected; bug was introduced after fork
CVE-2023-0215 | Use-after-free following BIO_new_NDEF | Moderate | Not affected; bug is in code that was removed from BoringSSL
CVE-2022-4450 | Double free after calling PEM_read_bio_ex | Moderate | Not affected; bug was introduced after fork
CVE-2023-0216 | Invalid pointer dereference in d2i_PKCS7 functions| Moderate | Not affected; bug is in code that was removed from BoringSSL
CVE-2023-0217 | NULL dereference validating DSA public key| Moderate | Not affected; bug was introduced after fork
CVE-2023-0401 | NULL dereference during PKCS7 data verification | Moderate | Not affected; bug is in code that was removed from BoringSSL

[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity

## CVE-2023-0286 - X.400 address type confusion in X.509 GeneralName

BoringSSL is affected by this bug. We discovered it in the course of revising the X.509 parsing logic, and reported it to OpenSSL. We landed a fix on February 7th, 2023 at revision [f219ae96bef](https://boringssl.googlesource.com/boringssl/+/f219ae96bef5be04e78ddb5b5226ccb6439bd3ed).

This bug is very similar to [CVE-2020-1971](https://www.openssl.org/news/secadv/20201208.txt), except this time the underlying type confusion admits more attacks than a NULL pointer dereference. Two conditions need to be met for the bug to be exploitable:

First, the application must enable CRL checking, which is off by default. Only applications that set the `X509_V_FLAG_CRL_CHECK` flag are potentially impacted.

Second, the attacker must have control over *both* the certificate being verified and the CRL it is checked against. Control over the certificate is common—the bug is before signature verification, and certificates are typically sourced from the network during verification. The second is less common. OpenSSL and BoringSSL do not provide APIs that automatically download CRLs from the network, so to be vulnerable, an application must implement this functionality themselves, or source attacker-controlled CRLs in some other way.

Applications may additionally be vulnerable if they inspect the `x400Address` field of the `GENERAL_NAME` structure as, before the fix, the declared type in the C headers did not match the actual structure in memory. However, as X.400 addresses are unused in modern X.509, we do not believe any such applications exist.

## CVE-2022-4304 - Timing Oracle in RSA Decryption

BoringSSL is not affected by this bug. This is an instance of a general timing leak caused by the `bn_correct_top` invariant in OpenSSL's big integer library. BoringSSL addressed the underlying leak in 2018 and [described our approach](https://github.com/openssl/openssl/issues/6640) to OpenSSL at the time.

Prompted by this advisory, we revisited our [Valgrind](https://boringssl-review.googlesource.com/c/33504)-based constant-time validation and noticed some of our constant-time protections elsewhere were being broken by compilers. We addressed this in two changes: [1](https://boringssl.googlesource.com/boringssl/+/53b876a4d15da0145495ec3a17521a2690fe5978) and [2](https://boringssl.googlesource.com/boringssl/+/d4396e387c820198f509a6927facea84592cddd8). These are different from the `bn_correct_top` issue, and we know of no concrete attack, but we point them out here for consumers concerned with side channels. They do not apply to assembly-enabled x86_64 builds.

(There is no language or compiler support for expressing constant-time constraints in C. While it broadly works in practice, all constant-time code must make assumptions about compiler optimizations, which is an inherently moving target. We use a combination of [Valgrind](https://boringssl-review.googlesource.com/c/33504) to check the compiler output and [optimization barriers](https://boringssl-review.googlesource.com/c/boringssl/+/36484) where we find problems.)
