X509_VERIFY_PARAM_inherit/_set1: refuse if either params are poisoned. Before, these functions would unconditionally copy the src's poison flag to the dst, potentially resulting in an unpoisoned context even if the reason for poisoning (e.g. a field with invalid value) remains. After this change, copying always fails if any of the two params is poisoned. The most relevant code path for this is when `X509_STORE_CTX_init` is called with a poisoned `X509_STORE`; it happily copied the poisoned context and then cleared the poison flag while inheriting from defaults. Yes, instead the calls in `X509_STORE_CTX_init` could be reversed to first `inherit` from the defaults and then to `set1` from the user provided context, which then would yield the correct copied poison flag; however it seems prudent to instead harden the public APIs, as there could be more issues of this kind. Not considering a vulnerability as the poison flag can only ever be set on a call to us if a caller used an API wrong by ignoring its return value. Of course, the whole purpose of the flag is to detect and fail such callers so no damage happens. Change-Id: Iaed97dfa21863c882a0d46b1b8439ec06a6a6964 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/95527 Commit-Queue: Rudolf Polzer <rpolzer@google.com> Reviewed-by: Adam Langley <agl@google.com> Presubmit-BoringSSL-Verified: boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.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:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: