diff options
author | David Benjamin <davidben@google.com> | 2023-12-11 01:47:25 -0500 |
---|---|---|
committer | Tomas Mraz <tomas@openssl.org> | 2024-01-15 16:29:54 +0100 |
commit | 08cecb4448e990f7914ec1df97b1ee0ca9031643 (patch) | |
tree | 8ad966577bfdda69bff015b1f554faae2235abb3 /crypto/der_writer.c | |
parent | ffeae4c4e7d779746c661e7fe17a0a21cc36c974 (diff) | |
download | openssl-08cecb4448e990f7914ec1df97b1ee0ca9031643.tar.gz |
Add X509_STORE_get1_objects
X509_STORE_get0_objects returns a pointer to the X509_STORE's storage,
but this function is a bit deceptive. It is practically unusable in a
multi-threaded program. See, for example, RUSTSEC-2023-0072, a security
vulnerability caused by this OpenSSL API.
One might think that, if no other threads are mutating the X509_STORE,
it is safe to read the resulting list. However, the documention does not
mention that other logically-const operations on the X509_STORE, notably
certifcate verifications when a hash_dir is installed, will, under a
lock, write to the X509_STORE. The X509_STORE also internally re-sorts
the list on the first query.
If the caller knows to call X509_STORE_lock and X509_STORE_unlock, it
can work around this. But this is not obvious, and the documentation
does not discuss how X509_STORE_lock is very rarely safe to use. E.g.
one cannot call any APIs like X509_STORE_add_cert or
X509_STORE_CTX_get1_issuer while holding the lock because those
functions internally expect to take the lock. (X509_STORE_lock is
another such API which is not safe to export as public API.)
Rather than leave all this to the caller to figure out, the API should
have returned a shallow copy of the list, refcounting the values. Then
it could be internally locked and the caller can freely inspect the
result without synchronization with the X509_STORE.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23224)
Diffstat (limited to 'crypto/der_writer.c')
0 files changed, 0 insertions, 0 deletions