| commit | 8c8629bfd89436e5019b6bd3c65cff4bf1a76b76 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Mon Mar 13 11:58:08 2023 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Mar 21 16:28:49 2023 +0000 |
| tree | 635b5235bcddf91d25a32ea1bad6aff56c3bb6cc | |
| parent | 92de195169d26d9f5cec7ef34df9194e614e50f8 [diff] |
Represent unknown universal types with V_ASN1_OTHER OpenSSL's ASN1_STRING representation has many cases. There's a grab-bag V_ASN1_OTHER cases that can represent any element. But it is currently only used for non-universal tags. Unknown universal tags go into the type field directly. This has a few problems: - Certain high values, V_ASN1_NEG_INTEGER and V_ASN1_NEG_ENUMERATED, are treated special. This was one of the two causes behind CVE-2016-2108 and had to be worked around with V_ASN1_MAX_UNIVERSAL. - OpenSSL can never compatibly support a new universal type in a non-ASN1_STRING form. Otherwise ASN1_TYPE's union changes its in-memory representation. - It is a bit ambiguous when OpenSSL does or doesn't know the type. - This is broadly implemented by having a default in all the switch/cases, which is a little awkward. - It's yet another "unknown tag" case when V_ASN1_OTHER covers such cases just fine. Remove this representation and use V_ASN1_OTHER. This more unambiguously resolves CVE-2016-2108. ASN1_STRING's and ASN1_TYPE's respective type fields are now a closed set. Update the documenthation accordingly. Formally allowing universal types in ASN1_STRING also opens the door to clearing the ASN1_PRINTABLE mess (https://crbug.com/boringssl/412). BoringSSL currently rejects X.509 names that are actually valid, because the OpenSSL X509_NAME representation cannot represent them. This allows us to introduce an ASN1_STRING-based ANY representation, which just represents all non-ASN1_STRING types in an V_ASN1_OTHER. The implementation is a little clumsy (the way things tasn_dec.c is written, I had to introduce yet another check), but I'm hoping that, when the parser is rewritten with CBS, this can be integrated into a single type dispatch. Update-Note: This does not change the set of inputs accepted or rejected by the ASN.1 parser. It does, however, change the in-memory representation in edge cases. Unless the application was specifically inspecting the in-memory representation for these unknown types, we expect this to have no impact. Fixed: 561 Change-Id: Ibf9550e285ce50b11c7609d28b139354b9dd41dc Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58148 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: David Benjamin <davidben@google.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
There are other files in this directory which might be helpful: