OpenSSL have published a security advisory. 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; 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 |
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.
This bug is very similar to CVE-2020-1971, 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.
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 to OpenSSL at the time.
Prompted by this advisory, we revisited our Valgrind-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 and 2. 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 to check the compiler output and optimization barriers where we find problems.)