Publish historical advisories from 2021 and 2022 Bug: 479225940 Change-Id: I5b96899831485ebd0f3bc617014d1c0c0a3aa807 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/88167 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com>
diff --git a/docs/advisories/2021-02-16.md b/docs/advisories/2021-02-16.md new file mode 100644 index 0000000..95275f4 --- /dev/null +++ b/docs/advisories/2021-02-16.md
@@ -0,0 +1,11 @@ +# OpenSSL Advisory: February 16th, 2021 + +OpenSSL have published a [security advisory](https://openssl-library.org/news/secadv/20210216.txt). Here's how it affects BoringSSL: + +CVE | Summary | [Severity] in OpenSSL | Impact to BoringSSL +----|---------|-----------------------|--------------------- +CVE-2021-23841 | Null pointer deref in X509_issuer_and_serial_hash() | Moderate | Fixed; the affected function is unused, so we [removed](https://boringssl.googlesource.com/boringssl/+/ca2162d71902385dc740a385d20977d551d14e8f) it. +CVE-2021-23839 | Incorrect SSLv2 rollback protection | Low | Not affected; we removed SSLv2 padding in the initial fork. +CVE-2021-23840 | Integer overflow in CipherUpdate | Low | Fixed; patch [imported](https://boringssl.googlesource.com/boringssl/+/e7c0c9734f5491e62665ea156603209a80fbb235). Note this only affects callers that decrypt around 2³¹ bytes with `EVP_CIPHER`. We recommend switching to `EVP_AEAD`, which uses `size_t` and passes output bounds explicitly. + +[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity
diff --git a/docs/advisories/2021-03-25.md b/docs/advisories/2021-03-25.md new file mode 100644 index 0000000..27ea160 --- /dev/null +++ b/docs/advisories/2021-03-25.md
@@ -0,0 +1,20 @@ +# OpenSSL Advisory: March 25th, 2021 (BoringSSL Not Affected) + +OpenSSL have published a [security advisory](https://www.openssl.org/news/secadv/20210325.txt). Here's how it affects BoringSSL: + +CVE | Summary | [Severity] in OpenSSL | Impact to BoringSSL +----|---------|-----------------------|--------------------- +CVE-2021-3450 | CA certificate check bypass with X509_V_FLAG_X509_STRICT | High | Not affected, issue was introduced after fork +CVE-2021-3449 | NULL pointer deref in signature_algorithms processing | High | Not affected, issue was introduced after fork + +[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity + +## CVE-2021-3450: CA certificate check bypass with X509_V_FLAG_X509_STRICT + +BoringSSL is not affected. While `X509_V_FLAG_X509_STRICT` existed before the fork, the bug itself was introduced afterwards. The issue was in a check for explicitly-encoded elliptic curve parameters in the certificate. BoringSSL’s public key parser has rejected such inputs since December 2015, so we handle those elsewhere. + +## CVE-2021-3449: NULL pointer deref in signature_algorithms processing + +BoringSSL is not affected. The bug was introduced after the fork. It is triggered by TLS renegotiation in servers, which we removed in May 2015. + +The bug itself comes from a combination of mixing initial vs. renegotiation handshake state and forgetting to update both the pointer and length of a buffer together. BoringSSL keeps most handshake state on a separate `SSL_HANDSHAKE` structure which we destroy and recreate on each handshake. This reduces the risk of mixing state between initial and renegotiation handshakes. As part of our move to C++, we also moved most buffers in the TLS implementation to a `bssl::Array` structure which manages the pointer and length together.
diff --git a/docs/advisories/2021-08-24.md b/docs/advisories/2021-08-24.md new file mode 100644 index 0000000..5d29365 --- /dev/null +++ b/docs/advisories/2021-08-24.md
@@ -0,0 +1,20 @@ +# OpenSSL Advisory: August 24th, 2021 + +OpenSSL have published a [security advisory](https://www.openssl.org/news/secadv/20210824.txt). Here's how it affects BoringSSL: + +CVE | Summary | [Severity] in OpenSSL | Impact to BoringSSL +----|---------|-----------------------|--------------------- +CVE-2021-3711 | SM2 Decryption Buffer Overflow | High | Not affected; BoringSSL does not implement SM2. +CVE-2021-3712 | Read buffer overruns processing ASN.1 strings | Moderate | Affected; fixed as of commit 61f320874 + +[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity + +## CVE-2021-3712 + +The `ASN1_STRING` type represents its contents with a data pointer and a length. The contents may contain NUL bytes, and there is no guarantee that the string is NUL-terminated. For convenience, OpenSSL will NUL-terminate the value in some codepaths (e.g. parsing), but not in others. + +Parts of OpenSSL incorrectly relied on NUL-termination. These bugs were also present in BoringSSL and have been fixed as of commit 61f320874be3541087c9ba5e2f21c1ebbc90dbce. This has two consequences: + +First, if the `ASN1_STRING` came from a codepath that did not NUL-terminate, the function would run off the end of the buffer. This can crash or leak information. However, all `ASN1_STRING`s produced by parsing will NUL-terminate the string, so we expect most consumers will not be affected. + +Second, the function may truncate the value on an interior NUL byte. This wasn’t analyzed in the OpenSSL advisory. Callers trying to parse the result of print functions may get the wrong value and misinterpret names in a certificate. We do not recommend parsing print function output. Name constraint verification is affected, but we do not believe this allows bypassing a name-constrained intermediate. Finally, `X509_get1_email`, `X509_REQ_get1_email`, and `X509_get1_ocsp` could return a truncated value, different from what other code, e.g. name constraint checks, observed.
diff --git a/docs/advisories/2021-12-14.md b/docs/advisories/2021-12-14.md new file mode 100644 index 0000000..04a055f --- /dev/null +++ b/docs/advisories/2021-12-14.md
@@ -0,0 +1,21 @@ +# OpenSSL Advisory: December 14th, 2021 (BoringSSL Not Affected) + +OpenSSL have published a [security advisory](https://www.openssl.org/news/secadv/20211214.txt). Here's how it affects BoringSSL: + +CVE | Summary | [Severity] in OpenSSL | Impact to BoringSSL +----|---------|-----------------------|--------------------- +CVE-2021-4044 | Invalid handling of X509_verify_cert() internal errors in libssl | Moderate | Not affected, issue was introduced after fork + +[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity + +## CVE-2021-4044 + +BoringSSL is not affected. The issue was introduced after the fork, in OpenSSL 3.0. It was caused by mixing up return value conventions from the X.509 implementation, where either 0 or -1 may signal an error. + +To avoid similar issues, BoringSSL has narrowed APIs in other parts of the library to [only return 0](https://boringssl.googlesource.com/boringssl/+/HEAD/PORTING.md#return-values) on error. We plan to, but have not yet, do the same for the X.509 implementation. + +*Addendum January 28th, 2026: The `X509_verify_cert` function's return value was narrowed on [December 2023](https://boringssl-review.googlesource.com/c/boringssl/+/65067).* + +## 32-bit MIPS carry overflow + +OpenSSL 1.1.1m and OpenSSL 3.0.1 additionally include a fix for a [carry overflow bug](https://github.com/openssl/openssl/commit/e9e726506cd2a3fd9c0f12daf8cc1fe934c7dddb) on 32-bit MIPS. BoringSSL does not include OpenSSL’s MIPS assembly and is not affected by this bug.
diff --git a/docs/advisories/2022-01-28.md b/docs/advisories/2022-01-28.md new file mode 100644 index 0000000..664004a --- /dev/null +++ b/docs/advisories/2022-01-28.md
@@ -0,0 +1,13 @@ +# OpenSSL Advisory: January 28th, 2022 (BoringSSL Not Affected) + +OpenSSL have published a [security advisory](https://www.openssl.org/news/secadv/20220128.txt). Here's how it affects BoringSSL: + +CVE | Summary | [Severity] in OpenSSL | Impact to BoringSSL +----|---------|-----------------------|--------------------- +CVE-2021-4160 | BN_mod_exp may produce incorrect results on MIPS | Moderate | Not affected, impacted code was removed from BoringSSL in the initial fork + +[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity + +## CVE-2021-4160 + +This is the MIPS carry overflow bug previously described in our writeup for [December 14th, 2021](./2021-12-14.md). BoringSSL does not include OpenSSL’s MIPS assembly and is not affected by this bug.
diff --git a/docs/advisories/2022-03-15.md b/docs/advisories/2022-03-15.md new file mode 100644 index 0000000..b627515 --- /dev/null +++ b/docs/advisories/2022-03-15.md
@@ -0,0 +1,29 @@ +# OpenSSL Advisory: March 15th, 2022 + +OpenSSL have published a [security advisory](https://openssl-library.org/news/secadv/20220315.txt). Here's how it affects BoringSSL: + +CVE | Summary | [Severity] in OpenSSL | Impact to BoringSSL +----|---------|-----------------------|--------------------- +CVE-2022-0778 | Infinite loop in `BN_mod_sqrt`() reachable when parsing certificates | High | Mostly unaffected. See discussion below. + +[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity + +## CVE-2022-0778 + +BoringSSL shares the underlying bug in `BN_mod_sqrt` as OpenSSL, but it is mostly unaffected by the DoS vulnerability. In particular, this bug is *not* reachable in BoringSSL from certificate and other ASN.1 elliptic curve parsing code. Impact in BoringSSL is limited to: + +* Callers of `EC_GROUP_new_curve_GFp` that take untrusted curve parameters +* Callers of `BN_mod_sqrt` that take untrusted moduli + +`BN_mod_sqrt` implements the [Tonelli–Shanks algorithm](https://en.wikipedia.org/wiki/Tonelli%E2%80%93Shanks_algorithm), which requires a prime modulus. It was written such that, given a composite modulus, it would sometimes loop forever. + +Modular square roots are used when decoding compressed coordinates in elliptic curve cryptography (ECC). Like its multiplicative-group counterpart, ECC acts over pre-agreed curves (i.e. think of the curve as part of the selected algorithm). This ensures each party in a protocol can reason about preconditions, security levels, etc. However, the ECC encoding was initially highly-general and X9.62 includes a specifiedCurve form that spells out a nearly arbitrary curve formula. [RFC 5480](https://www.rfc-editor.org/rfc/rfc5480.html) forbids this form: + +> specifiedCurve, which is of type SpecifiedECDomain type (defined +> in [X9.62]), allows all of the elliptic curve domain parameters +> to be explicitly specified. This choice MUST NOT be used. See +> Section 5, "ASN.1 Considerations". + +OpenSSL supports the specifiedCurve form and allows it to specify unrecognized curves. This allows attackers to control curve parameters, and thus to break `BN_mod_sqrt` preconditions. BoringSSL does not allow this. We do not support the specifiedCurve form in public keys. While we do support it in private keys, we still [only construct known curves](https://boringssl.googlesource.com/boringssl/+/81502beeddc5f116d44d0898c6c4a33057198db8/crypto/ec_extra/ec_asn1.c#373). + +The fix to `BN_mod_sqrt` has been imported as of [this change](https://boringssl-review.googlesource.com/c/boringssl/+/51925).
diff --git a/docs/advisories/2022-05-03.md b/docs/advisories/2022-05-03.md new file mode 100644 index 0000000..3c21b85 --- /dev/null +++ b/docs/advisories/2022-05-03.md
@@ -0,0 +1,12 @@ +# OpenSSL Advisory: May 3rd, 2022 (BoringSSL Not Affected) + +OpenSSL have published a [security advisory](https://mta.openssl.org/pipermail/openssl-announce/2022-May/000224.html). Here's how it affects BoringSSL: + +CVE | Summary | [Severity] in OpenSSL | Impact to BoringSSL +----|---------|-----------------------|--------------------- +CVE-2022-1292 | Failure to escape shell metacharacters. | Moderate | Not affected. BoringSSL does not contain this script. +CVE-2022-1343 | False-positive OCSP validation if OCSP_NOCHECKS set. | Moderate | Not affected. BoringSSL does not contain this code. +CVE-2022-1434 | RC4-MD5 ciphersuite used AAD as MAC key. | Low | Not affected. BoringSSL does not contain the affected code. +CVE-2022-1473 | Memory leak in OPENSSL_LH_flush | Low | Not affected. BoringSSL does not contain the affected code. + +[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity
diff --git a/docs/advisories/2022-06-21.md b/docs/advisories/2022-06-21.md new file mode 100644 index 0000000..c98f27f --- /dev/null +++ b/docs/advisories/2022-06-21.md
@@ -0,0 +1,21 @@ +# OpenSSL Advisory: June 21st, 2022 (BoringSSL Not Affected) + +OpenSSL have published a [security advisory](https://www.openssl.org/news/secadv/20220621.txt). Here's how it affects BoringSSL: + +CVE | Summary | [Severity] in OpenSSL | Impact to BoringSSL +----|---------|-----------------------|--------------------- +CVE-2022-2068 | The c_rehash script allows command injection | Moderate | Not affected. BoringSSL does not ship this script. + +[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity + +## Additional Changes in 1.1.1p + +The 1.1.1p release additionally includes the following changes: + +### Modular exponentiation fix + +The `BN_mod_exp_mont_consttime` function [would sometimes return the modulus when it should return zero](https://github.com/openssl/openssl/pull/18511). This fix was based on a corresponding BoringSSL fix ([part 1](https://boringssl.googlesource.com/boringssl/+/13c9d5c69d04485a7a8840c12185c832026c8315), [part 2](https://boringssl.googlesource.com/boringssl/+/801a801024febe1a33add5ddaa719e257d97aba5)), applied June 3rd, 2022. While this function is used in many cryptographic algorithms, we believe there is no security impact to algorithms implemented by BoringSSL. See the BoringSSL fix for more detailed analysis. + +### Lucky 13 mitigation + +The [Lucky 13](https://en.wikipedia.org/wiki/Lucky_Thirteen_attack) mitigation was [changed](https://github.com/openssl/openssl/pull/18050) to avoid leaking information under a model of cache line behavior. BoringSSL is not affected. We previously changed this logic in [September 2016](https://boringssl-review.googlesource.com/c/boringssl/+/11003/) to meet a stricter constant-time model, which makes no assumptions on the behavior of cache lines.
diff --git a/docs/advisories/2022-07-05.md b/docs/advisories/2022-07-05.md new file mode 100644 index 0000000..c507c96 --- /dev/null +++ b/docs/advisories/2022-07-05.md
@@ -0,0 +1,10 @@ +# OpenSSL Advisory: July 5th, 2022 (BoringSSL Not Affected) + +OpenSSL have published a [security advisory](https://www.openssl.org/news/secadv/20220705.txt). Here's how it affects BoringSSL: + +CVE | Summary | [Severity] in OpenSSL | Impact to BoringSSL +----|---------|-----------------------|--------------------- +CVE-2022-2274 | Heap memory corruption with RSA private key operation | High | Not affected. Bug was introduced after fork. +CVE-2022-2097 | AES OCB fails to encrypt some bytes | Moderate | Not affected. BoringSSL does not support OCB. + +[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity
diff --git a/docs/advisories/2022-10-11.md b/docs/advisories/2022-10-11.md new file mode 100644 index 0000000..dcb922d --- /dev/null +++ b/docs/advisories/2022-10-11.md
@@ -0,0 +1,15 @@ +# OpenSSL Advisory: October 11th, 2022 (BoringSSL Not Affected) + +OpenSSL have published a [security advisory](https://www.openssl.org/news/secadv/20221011.txt). Here's how it affects BoringSSL: + +CVE | Summary | [Severity] in OpenSSL | Impact to BoringSSL +----|---------|-----------------------|--------------------- +CVE-2022-3358 | Using a Custom Cipher with NID_undef may lead to NULL encryption | Low | Not affected; bug was introduced after fork and BoringSSL does not support custom `EVP_CIPHER`s + +[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity + +## Elliptic Curve Miscompilations + +Though not listed in the advisory, the 1.1.1r release additionally includes a [workaround](https://github.com/openssl/openssl/commit/6246649d657127a031782b29ba6132a4203260b2) for a [strict aliasing](https://en.cppreference.com/w/c/language/object#Strict_aliasing) issue which caused [miscompilations](https://github.com/openssl/openssl/issues/18225) of the elliptic curve (EC) code in recent versions of Clang. (The corresponding fix for 3.0.x was included in 3.0.4.) + +BoringSSL had long since replaced that code and was not affected by this issue. However, to avoid risking problems with future compilers, we [completely removed](https://boringssl-review.googlesource.com/c/boringssl/+/52505) union-based type-punning from our EC code in May 2022, and are working on [removing the remaining instances](https://bugs.chromium.org/p/boringssl/issues/detail?id=301). While C does allow some union-based type-punning, C++ is stricter and the C rules are complex enough that avoiding it is safer.
diff --git a/docs/advisories/2022-11-01.md b/docs/advisories/2022-11-01.md new file mode 100644 index 0000000..bd93438 --- /dev/null +++ b/docs/advisories/2022-11-01.md
@@ -0,0 +1,14 @@ +# OpenSSL Advisory: November 1st, 2022 (BoringSSL Not Affected) + +OpenSSL have published a [security advisory](https://www.openssl.org/news/secadv/20221101.txt). Here's how it affects BoringSSL: + +CVE | Summary | [Severity] in OpenSSL | Impact to BoringSSL +----|---------|-----------------------|--------------------- +CVE-2022-3602 | X.509 Email Address 4-byte Buffer Overflow | High (initially Critical) | Not affected. Bug was introduced after the fork. +CVE-2022-3786 | X.509 Email Address Variable Length Buffer Overflow | High | Not affected. Bug was introduced after the fork. + +[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity + +## TLS Cipher Strings + +Though not listed in the advisory, the 1.1.1s and 3.0.7 releases additionally fix an [out-of-bounds read](https://github.com/openssl/openssl/commit/9b3219ba544db82cdad3058b9872058739559944) in TLS cipher string processing. BoringSSL fixed this issue in [October 2016](https://boringssl-review.googlesource.com/c/boringssl/+/11421).
diff --git a/docs/advisories/2022-12-13.md b/docs/advisories/2022-12-13.md new file mode 100644 index 0000000..9ba7028 --- /dev/null +++ b/docs/advisories/2022-12-13.md
@@ -0,0 +1,9 @@ +# OpenSSL Advisory: December 13th, 2022 (BoringSSL Not Affected) + +OpenSSL have published a [security advisory](https://www.openssl.org/news/secadv/20221213.txt). Here's how it affects BoringSSL: + +CVE | Summary | [Severity] in OpenSSL | Impact to BoringSSL +----|---------|-----------------------|--------------------- +CVE-2022-3996 | X.509 Policy Constraints Double Locking | Low | Not affected; bug was introduced after fork. + +[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity
diff --git a/docs/advisories/2023-03-28.md b/docs/advisories/2023-03-28.md index f3540ed..5b0e65c 100644 --- a/docs/advisories/2023-03-28.md +++ b/docs/advisories/2023-03-28.md
@@ -7,6 +7,8 @@ CVE-2023-0465 | Invalid certificate policies in leaf certificates are silently ignored | Low | Fixed [December 2022](https://boringssl.googlesource.com/boringssl/+/d1b20a9580aebb6fbb0b1b2408cf1221d83afb71) CVE-2023-0466 | Certificate policy check not enabled | Low | See discussion below +[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity + ## CVE-2023-0465 We discovered this issue while working on the X.509 implementation in BoringSSL. This was fixed in BoringSSL on [December 20, 2022](https://boringssl.googlesource.com/boringssl/+/d1b20a9580aebb6fbb0b1b2408cf1221d83afb71). Applications that enable policy validation should update to `d1b20a9580aeb` or later.