We no longer need to define CRYPTO_MUTEX in public headers. This
simplifies a pile of things. First, we can now use pthread_rwlock_t
without any fuss, rather than trying to guess the size on glibc.
As a result, CRYPTO_MUTEX and CRYPTO_STATIC_MUTEX can be merged into one
type. We can almost do this to CRYPTO_refcount_t too. BIO is the one
straggler remaining.
Fixed: 325
Change-Id: Ie93c9f553c0f02ce594b959c041b00fc15ba51d2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60611
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
These bits need more work (and possibly some removal) as they're very,
very far from thread-safe, but rust-openssl relies on them being
const-correct when targetting OpenSSL 1.1.x.
Change-Id: I60531c7e90dbdbcb79c09fc440bd7c6b474172df
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60607
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
We now ensure STACK_OF(T) sizes and indices fit in INT_MAX, so it's safe
to cast to int.
Bug: 516
Change-Id: I33dd1de6d60a852d510b9b5c3ac70e2eacbc8905
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60066
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Prior to https://boringssl-review.googlesource.com/c/boringssl/+/58548,
ASN1_item_sign_ctx returned the length of the signature on success. It's
unclear why anyone would ever want this, but some test was sensitive to
it. (I think it was a typo.)
Restore the old behavior.
Change-Id: Ibf3e45331a339226744d51df703634d02b08a7c4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59307
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This reverts commit bab2f96e26. This
clears the sea of red in my editor.
Change-Id: I600ef6c36556fb526da729f0f0d8bc69db5c5a08
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59186
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These appear to be unused. Some ones of note:
- XN_FLAG_FN_ALIGN breaks with multi-attribute RDNs anyway
- XN_FLAG_FN_NONE is completely pointless
Update-Note: Some seemingly unused XN_FLAG_* values were removed. If
some project fails to build, we can put them back but one shouldn't be
using this function in the first place.
Change-Id: I4d8472e1e31aeec623b4d4e2aea48da7b1ef6798
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58930
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
They're not used anywhere, as X509_REQ doesn't expose the underlying
STACK_OF(X509_ATTRIBUTE) anyway. They're also very thin wrappers over
the stack functions, so just delete them and inline them into X509_REQ
functions.
While I'm here, I've tidied up the add1_attr_by_* functions to reduce an
unnecessary copy.
Change-Id: Iec002c83ab7ad7267314e98866d680d12a82e971
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58927
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I had a branch lying around to rewrite X509_NAME_print(_ex) because
those functions are a disaster, but it needs more work and probably
isn't high priority. In the meantime, document what we've got.
Also tidy up X509_print_ex slightly. m was completely unused and
some variable declarations could be moved closer to their definition.
Bug: 426
Change-Id: I24295048c36268c745f579ad66f34736cfe6830f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58925
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This reverts a small portion of
8c8629bfd8. The parsers for ANY remain
unchanged, but we inadvertently changed a corner case of ASN1_PRINTABLE
MSTRINGs. This is a huge mess.
utype in these switch cases is usually the type of the ASN1_ITEM, but,
with ANY and MSTRING, it is the tag of the value we found. (An MSTRING
or "multi-string" is a CHOICE of string-like types.)
When parsing ANY, this is moot because the is_supported_universal_type
logic ensures we'll never pass in an invalid type. When encoding ANY,
this only happens if you manually construct such an ASN1_TYPE.
MSTRINGs *should* be similar because of the bitmask they apply on tag
types. However, there is one MSTRING type whose bitmask,
B_ASN1_PRINTABLE, includes B_ASN1_UNKNOWN. ASN1_tag2bit, arbitrarily
maps eight unsupported tags to B_ASN1_UNKNOWN and instead of zero. These
are:
- ObjectDescriptor
- EXTERNAL
- REAL
- EMBEDDED PDV
- RELATIVE-OID
- TIME (note this is not the same as the X.509 Time CHOICE type)
- [UNIVERSAL 15], which is not even a defined type!
- CHARACTER STRING
(ENUMERATED is also mapped to B_ASN1_UNKNOWN, but it's supported.)
These eight tags were previously accepted in d2i_X509_NAME but
8c8629bfd8 inadvertently started rejecting
them. For now, restore the default in the switch/case so that we accept
them again. Per https://crbug.com/boringssl/412, attribute values are
ANY DEFINED BY types, so we actually should be accepting *all* types. We
do not, because B_ASN1_PRINTABLE is completely incoherent. But because
ANY is the correct type, going from the original incoherent set, to
this new, smaller incoherent set is arguably a regression.
This is a minimal fix. Long-term, we should handle that ANY correctly,
and avoid unexpected ASN1_STRING type values, by mapping all unsupported
types to V_ASN1_OTHER. This would allow us to support all types
correctly. A follow-up change will do that.
Update-Note: The X.509 name parser will go back to accepting a handful
of universal tag types that were inadvertently rejected in
8c8629bfd8. It is extremely unlikely that
anyone uses these as they're unsupported, obscure types. This CL also
makes our ASN1_TYPE encoder slightly more permissive again, if the
caller manually constructs an legacy in-memory representation of an
unsupported tag. But the follow-up change will restore the stricter
behavior.
Bug: 412, 561
Change-Id: Ia44a270f12f3021154761a1cd285707416d8787e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58705
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Also unexport PEM_proc_type and PEM_dek_info. They're never called
externally, just private functions within one file. Also, while I'm
here, fix the include guard on asn1/internal.h.
Bug: 516
Change-Id: I6961a65f638e7b464a8c349663898a954d7826b4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58548
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
If we see a critical policy constraints extension, we have two options:
We can either process it, which requires running policy validation, or
reject the certificate. We and OpenSSL do neither by default, which
means we may accept certificate chains that we weren't supposed to.
This fixes it by enabling X.509 policy validation unconditionally and
makes X509_V_FLAG_POLICY_CHECK moot. As a side effect, callers no longer
need to do anything for CVE-2023-0466.
This is the opposite of [0]'s advice, which instead recommends skipping
the feature and rejecting critical policy contraints. That would be a
good move for a new X.509 implementation. Policy validation is
badly-designed, even by X.509's standards. But we have OpenSSL's history
of previously accepting critical policy constraints (even though it
didn't check it). I also found at least one caller that tests a chain
with policy constraints, albeit a non-critical one.
We now have an efficient policy validation implementation, so just
enable it.
Of course, fixing this bug in either direction has compatibility risks:
either we take on the compat risk of being newly incompatible with
policyConstraints-using PKIs, or we take on the compat risk of newly
rejecting certificates that were invalid due to a policy validation
error, but no one noticed. The latter case seems safer because the chain
is unambiguously invalid.
Update-Note: X.509 certificate verification (not parsing) will now
notice policy-validation-related errors in the certificate chain. These
include syntax errors in policy-related extensions, and chains with a
requireExplicitPolicy policy constraint that are valid for no
certificate policies. Such chains are unambiguously invalid. We just did
not check it before by default. This is an obscure corner of X.509 and
not expected to come up in most PKIs.
[0] https://www.ietf.org/archive/id/draft-davidben-x509-policy-graph-01.html#section-3.4.4
Fixed: 557
Change-Id: Icc00c7797bb95fd3b14570eb068543fd83cda7b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58426
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
OpenSSL interprets NULL and empty lists as {anyPolicy}. I intended to
implement this, but didn't quite get the NULL case right. Fix this and
add a test.
Change-Id: I50dbf02695f424697e28a6e0ec4fd50b2822f44f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58425
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This was not thread-safe and, until the previous CL, egregiously so. No
one uses this API, so remove it.
Update-Note: Various unused functions for registering named
X509_VERIFY_PARAMs were removed. These functions only exist to make
X509_VERIFY_PARAM_lookup return a custom value. Instead, applications
that want a particular X509_VERIFY_PARAM can just configure it directly,
rather than stashing it in library-global state and then looking it back
up with X509_VERIFY_PARAM_lookup.
Change-Id: I8d532a1a137c7abbc131f2cb5d12ba94e5728e2d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58386
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This is a double-pointer and both layers should be const. This matches
OpenSSL 1.1.1, so in addition to being more const-correct, we're more
OpenSSL-compatible.
Update-Note: Anything that defines a comparison function would need to
fix the type signature. I found only one external caller, Envoy, that
defines it. https://github.com/envoyproxy/envoy/pull/25051 fixes it.
(That we hadn't run into the upstream incompatibility suggests this is
just not a feature folks use outside the library much.)
Bumping BORINGSSL_API_VERSION, in case I missed any, and there's some
caller where we can't just use C++14 generic lambdas to smooth it over.
Fixed: 498
Change-Id: I8f07ff42215172aa65ad8819acf69b63d6d8e54c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56190
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These functions need a lot more work, documentation, warnings
that using them isn't a good idea, and really we should just remove them
entirely.
But, for now, this is a minimal fix to the most egregious of issues: not
only are the functions themselves not thread-safe (i.e. you must call it
in some program-global initialization), but using them puts you in a
state where future uses of the X.509 library are not thread-safe! Fix
the latter by sorting the list at the point we're already mutating
things.
Re-sorting a list after every addition is not a particularly sensible
implementation, but we can assume these lists will only ever contain
O(1) entries.
(The sort calls date to
https://boringssl-review.googlesource.com/c/boringssl/+/27304, but the
issue was there before. Prior to that CL, sk_FOO_find implicitly sorted
the list. That CL made sk_FOO_find itself a const operation, necessary
for this, and just added explicit sk_FOO_sort calls to preserve the
existing behavior, initially.)
Change-Id: I063b8e708eaf17dfe66c5a3e8d33733adb3297e9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58385
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
I mistakenly thought no one needed X509 as an ASN1_ITEM, but that wasn't
true. wpa_supplicant relies on this. Restore this and add a test for it.
As with the rest of the rewrite, this is currently a little tedious. I'm
hoping that, as the internals are rewritten with CBS and CBB, we can
establish some cleaner patterns and abstractions.
Bug: 547
Change-Id: I761ee058f8ec916b2ec7f4730a764d46d72f1f10
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58285
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Now that the preceding CL has isolated the X.509 signature hack, we can
apply the strictness across the legacy parser. This is particularly
important for the TBSCertificate parser, where it is ambiguous which
value one checks the signature over. (Officially, you're supposed to
re-encode as DER. In practice, people don't do this.)
This change means many of our primitive types are actually parsed as
DER. I've removed the bug references in the comment in the documentation
where I believe they're finally correct.
Update-Note: Non-minimal lengths in certificates are no longer accepted,
as required for standards compliance. The one exception is the signature
field, where we still carry an exception. Some of this was already
enforced by libssl's parser.
Bug: 354
Change-Id: I57cfa7df9e1ec5707390e9b32fe1ec6b5d8172f9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58186
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This is a cursory conversion and is, currently, very tedious because it
needs to bridge calling conventions. After tasn_*.c and all the
underlying primitives have CBS/CBB-based calling conventions, this
should be a lot cleaner.
This is to break a dependency cycle:
- We'd like to rewrite d2i_X509 with CBS
- To do that, we need to rewrite its underlying types with CBS
- Those parsers are tied up in tasn_dec.c, so we effectively need to
rewrite tasn_dec.c with CBS.
- CBS is designed for DER, not BER, so such a change would most
naturally switch the TLV parser to require DER.
- We've *almost* done that already except
https://boringssl-review.googlesource.com/c/boringssl/+/51626 had to
stop at non-minimal definite lengths, which are allowed in BER but
forbidden in DER. See b/18228011 for a bunch of certificates which
have a non-minimal definite length at *just* the signature field.
- So, to do that, we'd ideally special case just that field, or BIT
STRINGs in general, to tolerate minimal lengths. That's easiest done
when d2i_X509 is CBS, so we can just do what we want in imperative
code. And thus we're back full circle.
So, detach X509 from the templates now. It's a bit tedious because we
need to switch calling conventions for now, but it breaks the cycle.
Later, we can revisit this and get all the benefits of a fully CBS-based
path.
For now, I haven't added an ASN1_ITEM. If it comes up, we can make an
EXTERN ASN1_ITEM.
Update-Note: The ASN1_ITEM removal means custom ASN.1 templates (which
are discouraged in favor of our much simpler CBS and CBB types) using
X509 will fail to compile. We don't believe anyone is relying on this,
but this can be restored if we find something.
Update-Note: Certificate parsing is slightly stricter: the outermost
TLVs, except for the signature field, no longer accept non-minimal
lengths, as mandated by DER. This strictness was broadly already applied
by the libssl parser.
Bug: 547
Change-Id: Ie5ad8ba4bb39f54fdd3dd45c53965b72a3850709
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58185
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
RDNs are a SET OF attributes which means they should be sorted by
DER encoding length, then lexicographically. We didn't have any test
coverage for this.
Bug: 548
Change-Id: I542196aae26984aeee4f1c6774878b121675b0dc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58025
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
This convention seems to break with some other tooling we have. Until we
figure out how to resolve that, remove the lines.
This partially reverts 54b04fdc21 but
keeps the fixes to the license header comments.
Change-Id: I4f08a9f3daf65d17b4c78ac6f4ac3de234ec3436
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57366
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
While hiding 'type' isn't such a huge deal, accessing 'pkey' without a
type check is very dangerous. The accessors are type-checked and avoid
this problem. It also gets us slightly closer to not needing to utter
CRYPTO_refcount_t in public headers, as we're currently not quite
declaring it right. And it allows us to remove another union:
https://boringssl-review.googlesource.com/c/boringssl/+/57106
This matches what upstream did in OpenSSL 1.1.0.
Update-Note: Code that reaches into the EVP_PKEY struct will no longer
compile, like in OpenSSL. I believe I've fixed all the cases. If I
missed any, the fix is to switch code to accessors. EVP_PKEY_id(pkey)
for pkey->type is the most common fix.
Change-Id: Ibe8d6b6cb8fbd141ea1cef0d02dc1ae3703e9469
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57105
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Change-Id: I0b1ba546374aa8b0fe79528f56e19f261536e565
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57305
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Nothing uses this, and the code is somewhat decrepit. Instead of
fixing it and continuing to maintain it as attack surface, we
send this off to the farm where it can run and play all day with
the other unused X.509 extensions.
Update-note: This removes the proxy certificate extension from
the recognized certificate extensions. Previously by default
a certificate with a critical proxy certificate extension would
have been rejected with "proxy certificate not allowed", but
will now be rejected with an unrecognized critical extension
error.
Fixed: 568
Change-Id: I5f838d69c59517254b4fa83f6e2abe6057fa66c7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57265
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
Remove all the other ERR_R_MALLOC_FAILURES from the
codebase.
Also changes cbb to push to the error stack, to correctly
report cbb failures instead of now only reporting
malloc failures. Previously it turned all cbb failures
into a malloc failure
Bug: 564
Change-Id: Ic13208bf9d9aaa470e83b2f15782fc94946bbc7b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57046
Auto-Submit: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Decoding from decimal takes quadratic time, and BN_dec2bn will happily
decode however large of input you pass in. This frustrates fuzzers.
I've added a cap to the input length in s2i_ASN1_INTEGER for now, rather
than BN_dec2bn, because we've seen people use BN for surprisingly large
calculator operations, and BN generally doesn't cap inputs to quadratic
(or worse) algorithms beyond memory limits. (We generally rely on
cryptography using fixed parameter sizes, though RSA, DSA, and DH were
misstandardized and need ad-hoc limits everywhere.)
Update-Note: The stringly-typed API for constructing X.509 extensions
now has (very generous) maximum input length for decimal integers of
8,192 digits. If anyone was relying on a higher input, this will break.
This is unlikely and should be caught by unit tests; if a project hits
this outside of tests, that means they are passing untrusted input into
this function, which is a security vulnerability in itself, and means
they especially need this change to avoid a DoS.
Bug: chromium:1415108
Change-Id: I138249d23ca6b1996f8437dba98633349bb3042b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57205
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
The output of ASN1_generate_v3 is *mostly* linear with the input, except
SEQ and SET reference config sections. Sections can be referenced
multiple times, and so the structure grows exponentially.
Cap the total output size to mitigate this. As before, we don't consider
these functions safe to use with untrusted inputs, but unbounded growth
will frustrate fuzzing. This CL sets the limit to 64K, which should be
enough for anyone. (This is the size of a single X.509 extension,
whereas certificates themselves should not get that large.)
While not strictly necessary, this also rearranges the
ASN1_mbstring_copy call to pass in a maximum output. This portion does
scale linearly with the output, so it's fine, but the fuzzer discovered
an input with a 700K-byte input, which, with fuzzer instrumentation and
sanitizers, seems to be a bit slow. This change should help the fuzzer
get past those cases faster.
Update-Note: The stringly-typed API for constructing X.509 extensions
now has a maximum output size. If anyone was constructing an extension
larger than 64K, this will break. This is unlikely and should be caught
by unit tests; if a project hits this outside of tests, that means they
are passing untrusted input into this function, which is a security
vulnerability in itself, and means they especially need this change to
avoid a DoS.
Bug: oss-fuzz:55725
Change-Id: Ibb65854293f44bf48ed5855016ef7cd46d2fae77
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57125
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
We still keep time_t stuff around for calling time() and
for external interfaces that are meant to give you time_t
values, but we stop using time_t internally. For publicly
exposed and used inputs that rely on time_t, _posix versions are
added to support providing times as an int64_t, and internal
use is changed to use the _posix version.
Several legacy functions which are extensivly used and
and use pointers to time_t are retained for compatibility,
along with posix time versions of them which we use exclusively.
This fixes the tests which were disabled on 32 bit platorms
to always run.
Update-Note: This is a potentially breaking change for things
that bind to the ASN1_[UTC|GENERALIZED]TIME_set and ASN1_TIME_adj
family of functions (and can not type convert a time_t to an
int64).
Bug: 416
Change-Id: Ic4daba5a299d8f35191853742640750a1ecc53d6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54765
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The "object reuse" mode in d2i_FOO is extremely problematic. See bug for
details. When we rewrite d2i_RSAPublicKey, etc., with CBS, we switched
dropped this fragile behavior and replaced it with freeing the old value
and replacing it with the new value. Extend this behavior to all functions
generated by crypto/asn1 templates too.
In particular, tasn_dec.c already frees the original object on error,
which means callers must already be prepared for OpenSSL to free their
reused object. The one caller I found that would be incompatible (via
both running tests and auditing callers) was actually broken due to this
error case, and has been fixed.
Update-Note: This slightly changes the calling convention of the d2i_FOO
functions. The change should be compatible with almost all valid calls.
If something goes wrong, it should hopefully be quite obvious. If
affected (or unaffected), prefer to set the output parameter to NULL
and use the return value instead.
Fixed: 550
Change-Id: Ie54cdf17f8f5a4d76fdbcddeaa27e6afd3fa9d8e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56647
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Instead, move the CRYPTO_BUFFER into ASN1_ENCODING (due to padding,
upgrading the two bitfields do a pointer doesn't increase memory usage),
and instead thread a CRYPTO_BUFFER parameter through tasn_dec.c.
Later, I want to reimplement the X509 and X509_CINF parsers with CBS/CBB
directly (https://crbug.com/boringssl/547), but that will be easier once
the whole crypto/asn1 machinery is rewritten with CBS/CBB
(https://crbug.com/boringssl/548). That, in turn, will be easier with
object reuse gone. But to get rid of object reuse, I need to remove the
one place in the library where we ourselves use it.
Bug: 550
Change-Id: Ia4df3da9280f808b124ac1f4ad58745dfe0f49e2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56646
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
GENERAL_NAME uses a weird ASN1_SEQUENCE item type. Test that serializing
it works.
Change-Id: I8d44eb637f58a9fbe870b1998b0d75e2bfcde601
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56986
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This fixes CVE-2023-0286.
The main impact is that GENERAL_NAME_cmp, when given x400Addresses, can
interpret a pointer with the wrong type. Applications that set
X509_V_FLAG_CRL_CHECK and take CRLs from untrusted sources should take
this patch.
Change-Id: Ib76265fa098df3cb0db075646773c14d59d0ca75
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56985
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Caught by running malloc failure tests on unit tests.
Bug: 563
Change-Id: Ic0167ef346a282dc8b5a26a1cedafced7fef9ed0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56927
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
The temporary X509_NAME wasn't destroyed if the section didn't exist.
Also document the weird 0 vs -1 convention (see callers), and revise the
NULL check added in
https://boringssl-review.googlesource.com/c/boringssl/+/56705. It
doesn't make a difference, but we should only apply the NULL check after
we've looked at the name, and return -1 because, after the name is
checked, it's a known syntax error.
Also fix a couple of comments that were wrong. It's that the RDNSequence
we take from X509_NAME must have one RDN, not that there's one
RDNSequence. (This is a consequence of X509_NAME's somewhat odd
in-memory representation.)
Bug: oss-fuzz:55700
Change-Id: I5745752bfa82802d361803868f962b2b0fa4bd32
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56929
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Handling of duplicate keys is all over the place. For set_reasons, it
tried to catch it but leaked memory. Also fix a hypothetical memory leak
in crldp_from_section, but I think it's actually impossible because any
list of CONF_VALUE from a section, rather than from X509V3_parse_list,
cannot have duplicates. It just overrides the previous value.
(Ideally we'd be consistent about whether duplicates override previous
values or are caught, but I'm opting to just leave the existing behavior
alone because no one should be using these APIs in the first place.)
Bug: oss-fuzz:55669
Change-Id: I95d23c257203dcd799d19f334ef847a97d060aad
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56865
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
If obj2 were invalid, obj1 leaks. Also both leak if creating the
POLICY_MAPPINGS object fails on allocation error. Just swap the order,
so the ASN1_OBJECTs go to an owned pointer from the start.
Bug: oss-fuzz:55636
Change-Id: Ibf0bf58f44db510623035004f6eb1e00961a5454
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56805
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Without a limit, a short input can translate into a very large allocation,
which is upsetting the fuzzers. Set a limit of 256, which allows up to a
32-byte allocation. (The highest bit index of any type in RFC 5280 is
8, so this is plenty of buffer.)
We do not consider this function to be safe with untrusted inputs (even
without bugs, it is prone to string injection vulnerabilities), so DoS
is not truly a concern, but the limit is necessary to keep fuzzing
effective.
Update-Note: If anyone is using FORMAT:BITLIST to create very large BIT
STRINGs, this will break. This is unlikely and should be caught by
unit tests; if a project hits this outside of tests, that means they are
passing untrusted input into this function, which is a security
vulnerability in itself, and means they especially need this change to
avoid a DoS.
Bug: oss-fuzz:55603
Change-Id: Ie9ec0d35c7d67a568371dfa961867bf1404f7e2f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56785
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Currently, the only EXTERN type is X509_NAME. Implicitly tagging an
X509_NAME didn't work anyway because of the cached encoding. Moreover,
even if it did work, it'd be invalid. Name in RFC 5280 is actually a
one-element CHOICE type, and CHOICE types can never be implicitly
tagged. So just remove support.
One thing of note: I'm thinking EXTERN can be used later to retain
ASN1_ITEM compatibility, once X509 and friends no longer use the
template machinery. That means we're not only assuming X509_NAME is
never implicitly tagged, but also that external callers using
<openssl/asn1t.h> won't implicitly tag a built-in type.
This removes a case we need to handle in the rewritten tasn_enc.c. (In
particular, crypto/asn1 and crypto/bytestring use a different tag
representation and I'd like to minimum the number of conversions we
need.)
Update-Note: IMPLEMENT_EXTERN_ASN1 can no longer be used outside the
library. I found no callers using this machinery, and we're better off
gradually migrating every <openssl/asn1t.h> user to CBS/CBB anyway.
Bug: 548
Change-Id: I0aab531077d25960dd3f16183656f318d78a0806
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56186
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This is an unexported API, so it's okay to change it. Many extension
types work by parsing a list of key:value pairs and then setting fields
based on it. If a key appears twice, it'll just overwrite the old value.
But X509V3_get_value_int forgot to free the old value when doing so.
Bug: oss-fuzz:55572
Change-Id: I2b39aa7e9214e82fb40ee2e3481697338fe88e1a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56745
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Also add some tests for this syntax. The error-handling here is slightly
subtle. Although we do call GENERAL_NAME_free on the temporary
GENERAL_NAME on error, GENERAL_NAME's value is freed based on the
type field. That means if you add an object to the value but don't set
the type, it won't be freed.
Only the OTHERNAME codepath was affected by this, and a malloc
failure-only case in the is_string path. I've gone ahead and reworked
all the paths so setting the type happens at the same time as setting
the value, so this invariant is more locally obvious.
This only impacts the unsafe, stringly-typed extensions-building APIs
that no one should be using anyway.
Bug: oss-fuzz:55569
Change-Id: I6390e4ac1142264cdc86f95fd850f1b8f81e3fc9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56725
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
gopls currently litters our project with a sea of red, because it
assumes Go files are part of a package, but we have a lot of standalone
Go scripts. (If there are C files in the same directory as the script,
it gets upset about cgo. If there are multiple standalone scripts in the
same directory, it gets uspet about duplicate files.)
Per https://github.com/golang/go/issues/49657 and
https://github.com/golang/tools/blob/master/gopls/doc/settings.md#standalonetags-string,
the convention seems to be a go:build ignore tag. Newer versions of
gopls run in a "standalone" mode, so we still get all the nice LSP
features.
As part of this, I had to align the license header comments from /*
block comments */ to // line comments. Go build constraints can only be
preceded by blank lines and line comments. Block comments apparently
aren't allowed. (See https://pkg.go.dev/cmd/go#hdr-Build_constraints.)
If I leave the file unconverted, go fmt will immediately move the
comment to above the license block.
Change-Id: I47c69255522e9aae2bdb97a6e83fcc6ce0cf29d5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56525
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
CONF_VALUEs are a mess. They show up in three forms:
- When parsed from a config file (in a CONF), I believe name and value
are never NULL.
- Internally, CONF represents sections as funny CONF_VALUEs where name
is NULL, and value is a STACK_OF(CONF_VALUE) of the wrong type. This
is ridiculous and should be a separate type, though I don't believe it
ever leaks outside the public API.
- When created by X509V3_parse_list, it is possible for them to be
value-less, with a NULL value.
v2i functions can see the last case, and set_dist_point_name comes from
a v2i function. Add a missing NULL check. This only impacts the unsafe,
stringly-typed extensions-building APIs that no one should be using
anyway.
Also fix the name of the test I added in the previous CL. I didn't quite
follow the existing convention.
Fixed: oss-fuzz:55558
Change-Id: I1a2403312f3ce59007d23fe7e226f2e602653019
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56705
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
See also upstream's abcf241114c4dc33af95288ae7f7d10916c67db0.
Fixed: oss-fuzz:55555, oss-fuzz:55556, oss-fuzz:55560
Change-Id: I3b015822806ced39a498017bd2329323ed8dfbf0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56685
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This improves the error-handling and uses CBB instead. It also resolves
a pile of -Wshorten-64-to-32 warnings. It also removes some of the calls
to ASN_put_object within the library.
The parsing uses NUL-terminated strings a bit because several of the
functions called at the end actually rely on the string being
NUL-terminated. Rather than pipe through (ptr, len) versions through
everything, I just used const char * or CBS based on whether the string
could be assumed to have a trailing NUL.
As part of this, I've made it reject [UNIVERSAL 0], matching all our
parsers. Rejecting that value means, since we don't have a nice
Option<T> in C, we can use zero in all the recursive calls to mean "no
implicit tag".
This does tighten the forms allowed for UTCTime a bit. I've disabled
allow_timezone_offset, while crypto/asn1 broadly still allows it. The
reasoning is this is code for constructing new certificates, not
consuming existing ones. If anything is calling this (hopefully not!) to
accidentally generate an invalid UTCTime, it should be fixed.
Update-Note: This code is reachable from the deprecated, string-based
X.509 extensions API. I've added tests for this, so it should behave
generally compatibly, but if anything changes for a caller using these
APIs, this CL is the likely cause. (NB: No one should be using these
APIs. They're fundamentally prone to string injection vulnerabilities.)
Bug: 516
Change-Id: I87f95e01ffbd22c4487d82c89ac098d095126cc1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56166
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Between the type being sometimes a tri-state and capturing the
underlying DER/BER representation, this type is a bit confusing. Add
constants for these.
I've left a case in ASN1_TBOOLEAN unconverted because it's actually
wrong. It will be fixed in a subsequent CL.
Change-Id: I75d846af14f6b4cd5278c3833b979e89c92c4203
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56487
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The real isspace may give locale-dependent results, so use our own.
This also lets us simplify some of the silliness asn1_string_canon needs
to go through to never pass high bytes into isspace and islower. (I'm
otherwise leaving that function alone because I plan to, later, convert
the whole thing to CBS/CBB.)
Change-Id: Idd349095f3e98bf908bb628ea1089ba05c2c6797
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56486
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These values figure into X509_LOOKUP_hash_dir's on-disk format, so they
must remain stable. Record a couple of values to ensure this remains the
case.
Change-Id: I63afa970f8564e0836d78d00375eb5cd6d383bea
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56485
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
https://boringssl-review.googlesource.com/c/boringssl/+/56109 tried to
simplify the X509V3_CTX story by automatically handling the second half
of initialization, but it turns out not all callers specify both values.
Instead, align with OpenSSL 3.0's behavior. Now X509V3_set_ctx
implicitly zeros the other fields, so it is the only mandatory init
function. This does mean callers which call X509V3_set_nconf before
X509V3_set_ctx will break, but that's true in OpenSSL 3.0 too.
I've retained the allowance for ctx being NULL, because whether
functions tolerate that or not is still a bit inconsistent. Also added
some TODOs about how strange this behavior is, but it's probably not
worth spending much more time on this code.
Change-Id: Ia04cf11eb5158374ca186795b7e579575e80666f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56265
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
David Benjamin
Bob Beck