| commit | 825bec8c8865e314bfc918c8ad352f154fdc4ba8 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Wed May 24 10:35:18 2023 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed May 24 17:25:03 2023 +0000 |
| tree | 55e92f6da5900c5301d24f00aab3120fba946984 | |
| parent | f31b45dbd1a18ddb60f5869ead81cd6f90ce3820 [diff] |
Remove variable expansion from CONF fuzzer CONF supports a variable expansion feature, which allows a config file to easily grow exponentially. 2d05568a7b7bc62affbd13ea97a81b5829b99794 (upstream's 6a6213556a80ab0a9eb926a1d6023b8bf44f2afd) capped the expansion to 65536 bytes, but this still allows a small input to produce a fairly large output. (Once we have one large value, it only takes five characters make a new key that references it, which is an expansion factor of around 13,000.) This, combined with the string-based extensions machinery's many quadratic behaviors (see b92fcfdc17f3ad794c220a86f4ae6695d0a0fb61), means fuzzers hit timeouts. We have very few uses of these APIs left, and none of them use this feature. Just remove it. While none of these super-linear behaviors are DoS bugs per se (they should never be passed untrusted input), there's no sense in carrying an unused feature that only frustrates the fuzzers. Update-Note: NCONF_load and NCONF_load_bio no longer support the $foo variable expansion syntax. If you are using these functions in your project, remove them. Bug: oss-fuzz:59049 Change-Id: I85832ae1d05373ee420f4fb68197786736ca8272 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60105 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@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: