tree 635b5235bcddf91d25a32ea1bad6aff56c3bb6cc
parent 92de195169d26d9f5cec7ef34df9194e614e50f8
author David Benjamin <davidben@google.com> 1678723088 -0400
committer Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> 1679416129 +0000

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>