The EVP_CIPHER api currently assumes that calls made into several APIs
have already initalized the cipher in a given context via a call to
EVP_CipherInit[_ex[2]]. If that hasnt been done, instead of an error,
the result is typically a SIGSEGV.
Correct that by adding missing NULL checks in the apropriate apis prior
to using ctx->cipher
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22995)
if the private key is output to stdout using the HARNESS_OSSL_PREFIX,
out is a stack of BIOs and must therefore free'd using BIO_free_all.
Steps to reproduce:
$ HARNESS_OSSL_PREFIX=x OPENSSL_CONF=apps/openssl.cnf util/shlib_wrap.sh apps/openssl req -new -keyout - -passout pass: </dev/null
[...]
Direct leak of 128 byte(s) in 1 object(s) allocated from:
#0 0x7f6f692b89cf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7f6f686eda00 in CRYPTO_malloc crypto/mem.c:202
#2 0x7f6f686edba0 in CRYPTO_zalloc crypto/mem.c:222
#3 0x7f6f68471bdf in BIO_new_ex crypto/bio/bio_lib.c:83
#4 0x7f6f68491a8f in BIO_new_fp crypto/bio/bss_file.c:95
#5 0x555c5f58b378 in dup_bio_out apps/lib/apps.c:3014
#6 0x555c5f58f9ac in bio_open_default_ apps/lib/apps.c:3175
#7 0x555c5f58f9ac in bio_open_default apps/lib/apps.c:3203
#8 0x555c5f528537 in req_main apps/req.c:683
#9 0x555c5f50e315 in do_cmd apps/openssl.c:426
#10 0x555c5f4c5575 in main apps/openssl.c:307
#11 0x7f6f680461c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
SUMMARY: AddressSanitizer: 128 byte(s) leaked in 1 allocation(s).
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23365)
actions-rs/toolchain is unmaintained and generates warnings
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23232)
CLA: trivial
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23345)
* iOS 6 and 7 got its last updates 2014.
* Adding -mios-simulator-version-min=14.0 to the configure command leads to two occurences of this parameter during compilation.
* So lets remove this values to allow a robust configuration from outside and avoid updates here in the future.
CLA: trivial
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23344)
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23307)
array"key" is uninitialized and it is being read directly in function SipHash_Init() as per the below statements making a way for the garbage values :
uint64_t k0 = U8TO64_LE(k);
uint64_t k1 = U8TO64_LE(k + 8);
CLA: trivial
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23298)
this could be triggered by the following code (assuming 64 bit time_t):
time_t t = 67768011791126057ULL;
ASN1_TIME* at = ASN1_TIME_set(NULL, t);
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22976)
this needs a sanitized 64 bit time_t build to be detected (or possibly
valgrind, trapv or similar)
Reviewed-by: Hugo Landau <hlandau@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22976)
Don't check the Max Fragment Length if the it hasn't been negotiated. We
were checking it anyway, and using the default value
(SSL3_RT_MAX_PLAIN_LENGTH). This works in most cases but KTLS can cause the
record length to actually exceed this in some cases.
Fixes#23169
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23182)
Check that we can write and read back long app data records when using
KTLS.
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23182)
Also document that it is ok to use this for control flow decisions.
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23304)
The function in question is SSL_get_peer_certificate()
CLA: trivial
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23315)
ubsan on clang17 has started warning about the following undefined
behavior:
crypto/lhash/lhash.c:299:12: runtime error: call to function err_string_data_hash through pointer to incorrect function type 'unsigned long (*)(const void *)'
[...]/crypto/err/err.c:184: note: err_string_data_hash defined here
#0 0x7fa569e3a434 in getrn [...]/crypto/lhash/lhash.c:299:12
#1 0x7fa569e39a46 in OPENSSL_LH_insert [...]/crypto/lhash/lhash.c:119:10
#2 0x7fa569d866ee in err_load_strings [...]/crypto/err/err.c:280:15
[...]
The issue occurs because, the generic hash functions (OPENSSL_LH_*) will
occasionaly call back to the type specific registered functions for hash
generation/comparison/free/etc, using functions of the (example)
prototype:
[return value] <hash|cmp|free> (void *, [void *], ...)
While the functions implementing hash|cmp|free|etc are defined as
[return value] <fnname> (TYPE *, [TYPE *], ...)
The compiler, not knowing the type signature of the function pointed to
by the implementation, performs no type conversion on the function
arguments
While the C language specification allows for pointers to data of one
type to be converted to pointers of another type, it does not
allow for pointers to functions with one signature to be called
while pointing to functions of another signature. Compilers often allow
this behavior, but strictly speaking it results in undefined behavior
As such, ubsan warns us about this issue
This is an potential fix for the issue, implemented using, in effect,
thunking macros. For each hash type, an additional set of wrapper
funtions is created (currently for compare and hash, but more will be
added for free/doall/etc). The corresponding thunking macros for each
type cases the actuall corresponding callback to a function pointer of
the proper type, and then calls that with the parameters appropriately
cast, avoiding the ubsan warning
This approach is adventageous as it maintains a level of type safety,
but comes at the cost of having to implement several additional
functions per hash table type.
Related to #22896
Reviewed-by: Sasa Nedvedicky <sashan@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23192)
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/19948)
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/19948)
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/19948)
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/19948)
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/19948)
The regression was introduced in PR #22817.
In that pull request, the input length check was moved forward,
but the related ori instruction was missing, and it will cause
input of any length down to the much slower scalar implementation.
Fixes#23300
CLA: trivial
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23301)
GNU/Hurd does not have IP_PKTINFO yet, thus SUPPORT_LOCAL_ADDR is undef,
data->local_addr_enabled never set to 1, and thus the M_METHOD_RECVMSG
method would end up raising BIO_R_LOCAL_ADDR_NOT_AVAILABLE immediately.
Fixes#22872
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23293)
During creation of the EVP_PKEY_CTX we were trying to discover what legacy
alg it corresponds to every time which was slow. Instead we move this into
the construction of the EVP_KEYMGMT.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23265)
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)
Since new_line is assigned with 0 in the very begging of the function check added at line no. 106 will never become true. Hence removing.
CLA: trivial
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23284)
Fixes CVE-2023-6237
If a large and incorrect RSA public key is checked with
EVP_PKEY_public_check() the computation could take very long time
due to no limit being applied to the RSA public key size and
unnecessarily high number of Miller-Rabin algorithm rounds
used for non-primality check of the modulus.
Now the keys larger than 16384 bits (OPENSSL_RSA_MAX_MODULUS_BITS)
will fail the check with RSA_R_MODULUS_TOO_LARGE error reason.
Also the number of Miller-Rabin rounds was set to 5.
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23243)
If the value of a->length is large (>= 2^12), then an integer overflow will
occur for the signed type, which according to the C standard is UB.
CLA: trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23274)
This changeset adds the counterpart to the '-subj' option to allow overriding
the Issuer. For consistency, the `-subj` option is aliased to `-set_subject`.
The issuer can be specified as following apps/openssl x509 -new -set_issuer
'/CN=example-nro-ta' -subj '/CN=2a7dd1d787d793e4c8af56e197d4eed92af6ba13' ...
This is useful in constructing specific test-cases or rechaining PKI trees
Joint work with George Michaelson (@geeohgeegeeoh)
Reviewed-by: Neil Horman <nhorman@openssl.org>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23257)
Current PowerPC-related defines omit Darwin ppc64 case.
Use __POWERPC__ in place of __ppc__ + __ppc64__
Fixes#23220
CLA: trivial
Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23245)
