| commit | edbdc240ecb6a2d5a500b8e2eedfe3e6a2423c0a | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue Nov 02 11:37:22 2021 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Apr 19 18:42:59 2022 +0000 |
| tree | bfbe2c2b54480d5d7a72bd2a079de96229aa7201 | |
| parent | 2fc6d38391cb76839c76b2a462619e7d69fd998d [diff] |
Reject [UNIVERSAL 0] in DER/BER element parsers. [UNIVERSAL 0] is reserved by X.680 for the encoding to use. BER uses this to encode indefinite-length EOCs, but it is possible to encode it in a definite-length element or in a non-EOC form (non-zero length, or constructed). Whether we accept such encodings is normally moot: parsers will reject the tag as unsuitable for the type. However, the ANY type matches all tags. Previously, we would allow this, but crypto/asn1 has some ad-hoc checks for unexpected EOCs, in some contexts, but not others. Generalize this check to simply rejecting [UNIVERSAL 0] in all forms. This avoids a weird hole in the abstraction where tags are sometimes representable in BER and sometimes not. It also means we'll preserve this check when migrating parsers from crypto/asn1. Update-Note: There are two kinds of impacts I might expect from this change. The first is BER parsers might be relying on the CBS DER/BER element parser to pick up EOCs, as our ber.c does. This should be caught by the most basic unit test and can be fixed by detecting EOCs externally. The second is code might be trying to parse "actual" elements with tag [UNIVERSAL 0]. No actual types use this tag, so any non-ANY field is already rejecting such inputs. However, it is possible some input has this tag in a field with type ANY. This CL will cause us to reject that input. Note, however, that crypto/asn1 already rejects unexpected EOCs inside sequences, so many cases were already rejected anyway. Such inputs are also invalid as the ANY should match some actual, unknown ASN.1 type, and that type cannot use the reserved tag. Fixed: 455 Change-Id: If42cacc01840439059baa0e67179d0f198234fc4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52245 Reviewed-by: Adam Langley <agl@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: