OpenSSL have published a security advisory. 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. |
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:
EC_GROUP_new_curve_GFp that take untrusted curve parametersBN_mod_sqrt that take untrusted moduliBN_mod_sqrt implements the Tonelli–Shanks 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 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.
The fix to BN_mod_sqrt has been imported as of this change.