Matt Caswell [Tue, 6 Dec 2022 14:51:54 +0000 (14:51 +0000)]
Ensure ossl_cms_EncryptedContent_init_bio() reports an error on no OID
If the cipher being used in ossl_cms_EncryptedContent_init_bio() has no
associated OID then we should report an error rather than continuing on
regardless. Continuing on still ends up failing - but later on and with a
more cryptic error message.
Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19920)
Matt Caswell [Tue, 6 Dec 2022 14:35:53 +0000 (14:35 +0000)]
Fix BIO_f_asn1() to properly report some errors
Some things that may go wrong in asn1_bio_write() are serious errors
that should be reported as -1, rather than 0 (which just means "we wrote
no data").
Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19920)
Matt Caswell [Tue, 6 Dec 2022 14:21:23 +0000 (14:21 +0000)]
Fix SMIME_crlf_copy() to properly report an error
If the BIO unexpectedly fails to flush then SMIME_crlf_copy() was not
correctly reporting the error. We modify it to properly propagate the
error condition.
Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19920)
Matt Caswell [Tue, 6 Dec 2022 14:18:53 +0000 (14:18 +0000)]
Fix BIO_f_cipher() flushing
If an error occurs during a flush on a BIO_f_cipher() then in some cases
we could get into an infinite loop. We add a check to make sure we are
making progress during flush and exit if not.
This issue was reported by Octavio Galland who also demonstrated an
infinite loop in CMS encryption as a result of this bug.
The security team has assessed this issue as not a CVE. This occurs on
*encryption* only which is typically processing trusted data. We are not
aware of a way to trigger this with untrusted data.
Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19920)
Bernd Edlinger [Wed, 16 Nov 2022 11:32:06 +0000 (12:32 +0100)]
Fix a memory leak in rsa_priv_encode
If PKCS8_pkey_set0 fails, the memory in rk need to be clear freed
otherwise it is owned by the PKCS8_PRIV_KEY_INFO.
Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Todd Short <todd.short@me.com> Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19694)
Matt Caswell [Thu, 27 Oct 2022 13:14:53 +0000 (14:14 +0100)]
Fix the ceiling on how much encryption growth we can have
Stitched ciphersuites can grow by more during encryption than the code
allowed for. We fix the calculation and add an assert to check we go it
right.
Also if we are adding the MAC independently of the cipher algorithm then
the encryption growth will not include that MAC so we should remove it
from the amount of bytes that we reserve for that growth. Otherwise we
might exceed our buffer size and the WPACKET_reserve operation will
fail.
Note that this is not a security issue. Even though we can overflow the
amount of bytes reserved in the WPACKET for the encryption, the underlying
buffer is still big enough.
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19585)
Tomas Mraz [Tue, 1 Nov 2022 10:50:22 +0000 (11:50 +0100)]
Update CHANGES and NEWS for new release
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19558)
Richard Levitte [Wed, 6 Jul 2022 04:09:01 +0000 (06:09 +0200)]
Make openVMS seeding less dependent of OpenVMS version
SYS$GETTIM_PREC is a very new function, only available on OpenVMS v8.4.
OpenSSL binaries built on OpenVMS v8.4 become unusable on older OpenVM
versions, but building for the older CRTL version will make the high
precision time functions unavailable.
Tests have shown that on Alpha and Itanium, the time update granularity
between SYS$GETTIM and SYS$GETTIM_PREC is marginal, so the former plus
a sequence number turns out to be better to guarantee a unique nonce.
Fixes #18727
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18730)
If rule_str ended in a "-", "l" was incremented one byte past the
end of the buffer. This resulted in an out-of-bounds read when "l"
is dereferenced at the end of the loop. It is safest to just return
early in this case since the condition occurs inside a nested loop.
CLA: trivial
Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19166)
Fix many inconsistencies in doc of CMS_verify() and PKC7_verify() etc.
Also change B< to I< in {CMS,PKCS7}_verify.pod, PKCS7_sign{,_add_signer}.pod
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/19108)
The IRIX mips64-cpu, n32-abi configurations include SIXTY_FOUR_BIT in bn_ops,
but it is missing from mips64*-linux-*abin32 (which OpenSSL calls
"linux-mips64"). This causes heap corruption when verifying TLS certificates
(which tend to be RSA-signed) with openssl 1.1.1q:
Applying this patch and recompiling produces the expected output instead of a
crash.
Note that Gentoo (and to my knowledge all other other distributions which
support mips64n32) use the `linux-generic32` configuration, which uses only
32-bit arithmetic (rather than full 64-bit arithmetic) and lacks assembler
implementations for the SHA hash functions:
For support in nixpkgs we would like to use the full 64-bit integer registers
and perlasm routines, so I'm submitting this upstream as well.
Fixes #19319
CLA: trivial
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19320)
Gibeom Gwon [Sat, 27 Aug 2022 13:29:28 +0000 (22:29 +0900)]
X509 x_all.c: Set 'modified' flag when ASN1_item_sign{,_ctx} call was successful
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/18879)
Gibeom Gwon [Sat, 27 Aug 2022 13:04:38 +0000 (22:04 +0900)]
X509 x509_req.c: Set 'modified' flag when X509_req_info_st member data updated
We need to reencode X509_req_info_st if member data updated.
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/18879)
Daniel Fiala [Sun, 28 Aug 2022 09:53:32 +0000 (11:53 +0200)]
Convert serverinfo in SSL_CTX_use_serverinfo() to v2.
Fixes #18183.
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/19081)
Matt Caswell [Mon, 25 Jul 2022 14:59:38 +0000 (15:59 +0100)]
Fix SSL_pending() and SSL_has_pending() with DTLS
If app data is received before a Finished message in DTLS then we buffer
it to return later. The function SSL_pending() is supposed to tell you
how much processed app data we have already buffered, and SSL_has_pending()
is supposed to tell you if we have any data buffered (whether processed or
not, and whether app data or not).
Neither SSL_pending() or SSL_has_pending() were taking account of this
DTLS specific app data buffer.
Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18976)
This allows to set EC_KEY's private key to NULL and fixes regression
issue following OTC guideline in
https://github.com/openssl/openssl/issues/18744#issuecomment-1195175696
Fixes #18744.
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com> Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18874)
X509_REQ_get_extensions(): Return empty stack if no extensions found
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Todd Short <todd.short@me.com> Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/18926)
Bernd Edlinger [Wed, 5 Jan 2022 16:25:02 +0000 (17:25 +0100)]
Fix copyright year issues
Fixes: #13765 Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17706)
Pauli [Thu, 28 Jul 2022 01:23:29 +0000 (11:23 +1000)]
Note that EVP_CIPHER_iv_length returns negative values on error
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18894)
Checks if header is NULL or not before calling strlen().
CLA: trivial
Fixes #18825
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Ben Kaduk <kaduk@mit.edu> Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18865)
Matt Caswell [Fri, 10 Jun 2022 11:33:45 +0000 (12:33 +0100)]
Fix a crash in v2i_IPAddrBlocks()
If an IP address prefix value is supplied that is too large then a crash
can result. v2i_IPAddrBlocks() should sanity check the prefix value, as
should X509v3_addr_add_prefix().
Reported by Theo Buehler (@botovq)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18847)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18847)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18847)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18847)
Todd Short [Wed, 20 Jul 2022 20:42:50 +0000 (16:42 -0400)]
Fix re-signing certificates with different key sizes
PR #18129 broke the scenario of signing a certificate (not CSR) with
different-sized key. This works in 3.0, so port the fix from 3.0
(which is to only update the issuer for a request).
Partially undo #18129, but keep setting the issuer only for a CSR
Create two certs (a and ca) then sign a with c (into b):
```
openssl req -x509 -newkey rsa:2048 -keyout a-key.pem -out a-cert.pem -days 365 -nodes -subj /CN=a.example.com
openssl req -x509 -newkey rsa:4096 -keyout ${HERE}/ca-key.pem -out ${HERE}/ca-cert.pem -days 3650 -nodes -subj /CN=ca.example.com
openssl x509 -in a-cert.pem -CA ca-cert.pem -CAkey ca-key.pem -set_serial '1234567890' -preserve_dates -sha256 -out b-cert.pem
```
The above succeeds in 1.1.1n and 3.0, fails in 1.1.1o (which includes #18129)
The issue in #16080 is also fixed.
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/18836)
X509_STORE_CTX_purpose_inherit(): add missing details to its documentation
Fixes #18801
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com>
(Merged from https://github.com/openssl/openssl/pull/18830)
Fix verify_callback in the openssl s_client/s_server app
We need to check that error cert is available before printing its data
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com> Reviewed-by: Viktor Dukhovni <viktor@openssl.org> Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18805)
x509.pod: fix description of certificate serial number storage
Backported from https://github.com/openssl/openssl/pull/18373
Reviewed-by: Hugo Landau <hlandau@openssl.org> 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/18803)
APPS/x509: With -CA but both -CAserial and -CAcreateserial not given, use random serial.
Also improve openssl-x509.pod.in and error handling of load_serial() in apps.c.
Backported from https://github.com/openssl/openssl/pull/18373
Reviewed-by: Hugo Landau <hlandau@openssl.org> 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/18803)
Signed-off-by: Varun Sharma <varunsh@stepsecurity.io> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18766)
Bernd Edlinger [Sat, 23 Oct 2021 09:58:27 +0000 (11:58 +0200)]
Make the DRBG seed propagation thread safe
Currently there is a race possible because the reseed_counter
of the master drbg may be incremented after the get_entropy call.
Therefore access the parent's reseed_counter while still holding
the rand_drbg_lock.
This was found by my Reproducible Error Injection patch (#18356)
Due to the exact location of the injected memory
error the sha256 digest is missing, and this causes much later
the memory leak (and a failed assertion) in tls13_generate_secret.
But the reproduction is a bit challenging, as it requires AESNI
and RDRAND capability.
OPENSSL_ia32cap=0x4200000000000000 ERROR_INJECT=1657070330 ../util/shlib_wrap.sh ./client-test ./corpora/client/791afc153e17db072175eeef85385a38d7f6d194
#0 0x7fceaffb7d4f in __sanitizer_print_stack_trace ../../../../src/libsanitizer/asan/asan_stack.cc:36
#1 0x55fb9117f934 in my_malloc fuzz/test-corpus.c:114
#2 0x7fceafa147f3 in OPENSSL_LH_insert crypto/lhash/lhash.c:109
#3 0x7fceafa42639 in lh_OBJ_NAME_insert crypto/objects/obj_local.h:12
#4 0x7fceafa42639 in OBJ_NAME_add crypto/objects/o_names.c:236
#5 0x7fceaf9f7baa in EVP_add_digest crypto/evp/names.c:39
#6 0x7fceaf9c6b97 in openssl_add_all_digests_int crypto/evp/c_alld.c:39
#7 0x7fceafa0f8ec in ossl_init_add_all_digests crypto/init.c:275
#8 0x7fceafa0f8ec in ossl_init_add_all_digests_ossl_ crypto/init.c:264
#9 0x7fceaf69b4de in __pthread_once_slow /build/glibc-SzIz7B/glibc-2.31/nptl/pthread_once.c:116
#10 0x7fceafafb27c in CRYPTO_THREAD_run_once crypto/threads_pthread.c:118
#11 0x7fceafa1000e in OPENSSL_init_crypto crypto/init.c:677
#12 0x7fceafa1000e in OPENSSL_init_crypto crypto/init.c:611
#13 0x7fceafdad3e8 in OPENSSL_init_ssl ssl/ssl_init.c:190
#14 0x55fb9117ee0f in FuzzerInitialize fuzz/client.c:46
#15 0x55fb9117e939 in main fuzz/test-corpus.c:194
#16 0x7fceaf4bc082 in __libc_start_main ../csu/libc-start.c:308
#17 0x55fb9117ec7d in _start (.../openssl/fuzz/client-test+0x2c7d)
#0 0x7fceaffb7d4f in __sanitizer_print_stack_trace ../../../../src/libsanitizer/asan/asan_stack.cc:36
#1 0x55fb9117f934 in my_malloc fuzz/test-corpus.c:114
#2 0x7fceafa147f3 in OPENSSL_LH_insert crypto/lhash/lhash.c:109
#3 0x7fceafa42639 in lh_OBJ_NAME_insert crypto/objects/obj_local.h:12
#4 0x7fceafa42639 in OBJ_NAME_add crypto/objects/o_names.c:236
#5 0x7fceaf9f7baa in EVP_add_digest crypto/evp/names.c:39
#6 0x7fceafdad328 in ossl_init_ssl_base ssl/ssl_init.c:87
#7 0x7fceafdad328 in ossl_init_ssl_base_ossl_ ssl/ssl_init.c:24
#8 0x7fceaf69b4de in __pthread_once_slow /build/glibc-SzIz7B/glibc-2.31/nptl/pthread_once.c:116
#9 0x7fceafafb27c in CRYPTO_THREAD_run_once crypto/threads_pthread.c:118
#10 0x7fceafdad412 in OPENSSL_init_ssl ssl/ssl_init.c:193
#11 0x55fb9117ee0f in FuzzerInitialize fuzz/client.c:46
#12 0x55fb9117e939 in main fuzz/test-corpus.c:194
#13 0x7fceaf4bc082 in __libc_start_main ../csu/libc-start.c:308
#14 0x55fb9117ec7d in _start (.../openssl/fuzz/client-test+0x2c7d)
Direct leak of 80 byte(s) in 1 object(s) allocated from:
#0 0x7fceaffaa808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
#1 0x7fceafa19425 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fceafa03a85 in int_ctx_new crypto/evp/pmeth_lib.c:144
#3 0x7fceafa03a85 in EVP_PKEY_CTX_new_id crypto/evp/pmeth_lib.c:250
#4 0x7fceafe38de5 in tls13_generate_secret ssl/tls13_enc.c:174
#5 0x7fceafd9537f in ssl_derive ssl/s3_lib.c:4833
#6 0x7fceafdde91c in tls_parse_stoc_key_share ssl/statem/extensions_clnt.c:1902
#7 0x7fceafdd4ac1 in tls_parse_all_extensions ssl/statem/extensions.c:752
#8 0x7fceafdf8079 in tls_process_server_hello ssl/statem/statem_clnt.c:1698
#9 0x7fceafe01f87 in ossl_statem_client_process_message ssl/statem/statem_clnt.c:1034
#10 0x7fceafdeec0d in read_state_machine ssl/statem/statem.c:636
#11 0x7fceafdeec0d in state_machine ssl/statem/statem.c:434
#12 0x7fceafdb88d7 in SSL_do_handshake ssl/ssl_lib.c:3718
#13 0x55fb9117f07c in FuzzerTestOneInput fuzz/client.c:98
#14 0x55fb9117f463 in testfile fuzz/test-corpus.c:182
#15 0x55fb9117eb92 in main fuzz/test-corpus.c:226
#16 0x7fceaf4bc082 in __libc_start_main ../csu/libc-start.c:308
Indirect leak of 1080 byte(s) in 1 object(s) allocated from:
#0 0x7fceaffaa808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
#1 0x7fceafa19425 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fceafa11555 in pkey_hkdf_init crypto/kdf/hkdf.c:51
#3 0x7fceafa03b36 in int_ctx_new crypto/evp/pmeth_lib.c:160
#4 0x7fceafa03b36 in EVP_PKEY_CTX_new_id crypto/evp/pmeth_lib.c:250
#5 0x7fceafe38de5 in tls13_generate_secret ssl/tls13_enc.c:174
#6 0x7fceafd9537f in ssl_derive ssl/s3_lib.c:4833
#7 0x7fceafdde91c in tls_parse_stoc_key_share ssl/statem/extensions_clnt.c:1902
#8 0x7fceafdd4ac1 in tls_parse_all_extensions ssl/statem/extensions.c:752
#9 0x7fceafdf8079 in tls_process_server_hello ssl/statem/statem_clnt.c:1698
#10 0x7fceafe01f87 in ossl_statem_client_process_message ssl/statem/statem_clnt.c:1034
#11 0x7fceafdeec0d in read_state_machine ssl/statem/statem.c:636
#12 0x7fceafdeec0d in state_machine ssl/statem/statem.c:434
#13 0x7fceafdb88d7 in SSL_do_handshake ssl/ssl_lib.c:3718
#14 0x55fb9117f07c in FuzzerTestOneInput fuzz/client.c:98
#15 0x55fb9117f463 in testfile fuzz/test-corpus.c:182
#16 0x55fb9117eb92 in main fuzz/test-corpus.c:226
#17 0x7fceaf4bc082 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: 1160 byte(s) leaked in 2 allocation(s).
Reviewed-by: Todd Short <todd.short@me.com> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18725)
Alexander Scheel [Wed, 29 Jun 2022 14:19:58 +0000 (10:19 -0400)]
Fixes OSCP->OCSP typo in ocsp command line
The existing help text says:
> -badsig Corrupt last byte of loaded OSCP response signature (for test)
but this should be OCSP. This is the only occurrence within the project
of this typo.
CLA: trivial
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18684)
Bernd Edlinger [Sun, 12 Jun 2022 07:37:26 +0000 (09:37 +0200)]
Fix reported performance degradation on aarch64
This restores the implementation prior to
commit 2621751 ("aes/asm/aesv8-armx.pl: avoid 32-bit lane assignment in CTR mode")
for 64bit targets only, since it is reportedly 2-17% slower,
and the silicon errata only affects 32bit targets.
Only for 32bit targets the new algorithm is used.
Fixes #18445
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Hugo Landau <hlandau@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18539)
Gregor Jasny [Tue, 5 Jul 2022 10:57:06 +0000 (12:57 +0200)]
Add missing header for memcmp
CLA: trivial
Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Todd Short <todd.short@me.com> Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18719)
Add test vectors for AES OCB for x86 AES-NI multiple of 96 byte issue.
Co-authored-by: Alejandro Sedeño <asedeno@google.com> Co-authored-by: David Benjamin <davidben@google.com> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
aesni_ocb_encrypt and aesni_ocb_decrypt operate by having a fast-path
that performs operations on 6 16-byte blocks concurrently (the
"grandloop") and then proceeds to handle the "short" tail (which can
be anywhere from 0 to 5 blocks) that remain.
As part of initialization, the assembly initializes $len to the true
length, less 96 bytes and converts it to a pointer so that the $inp
can be compared to it. Each iteration of "grandloop" checks to see if
there's a full 96-byte chunk to process, and if so, continues. Once
this has been exhausted, it falls through to "short", which handles
the remaining zero to five blocks.
Unfortunately, the jump at the end of "grandloop" had a fencepost
error, doing a `jb` ("jump below") rather than `jbe` (jump below or
equal). This should be `jbe`, as $inp is pointing to the *end* of the
chunk currently being handled. If $inp == $len, that means that
there's a whole 96-byte chunk waiting to be handled. If $inp > $len,
then there's 5 or fewer 16-byte blocks left to be handled, and the
fall-through is intended.
The net effect of `jb` instead of `jbe` is that the last 16-byte block
of the last 96-byte chunk was completely omitted. The contents of
`out` in this position were never written to. Additionally, since
those bytes were never processed, the authentication tag generated is
also incorrect.
The same fencepost error, and identical logic, exists in both
aesni_ocb_encrypt and aesni_ocb_decrypt.
This addresses CVE-2022-2097.
Co-authored-by: Alejandro Sedeño <asedeno@google.com> Co-authored-by: David Benjamin <davidben@google.com> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
Matt Caswell [Fri, 10 Jun 2022 14:58:58 +0000 (15:58 +0100)]
Fix range_should_be_prefix() to actually return the correct result
range_should_be_prefix() was misidentifying whether an IP address range
should in fact be represented as a prefix. This was due to a bug introduced
in commit 42d7d7dd which made this incorrect change:
Bernd Edlinger [Fri, 17 Jun 2022 08:25:24 +0000 (10:25 +0200)]
Fix compile issues in test/v3ext.c with no-rfc3779
There are no ASIdentifiers if OPENSSL_NO_RFC3779 is defined,
therefore the test cannot be compiled.
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18634)
olszomal [Fri, 17 Jun 2022 13:01:11 +0000 (15:01 +0200)]
SSL_get_current_cipher() and SSL_get_pending_cipher() return 'const SSL_CIPHER *'
Fix the documentation.
CLA: trivial
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Todd Short <todd.short@me.com> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18599)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fb61945309f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fb619092430 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fb618ef5f11 in BN_new crypto/bn/bn_lib.c:246
#3 0x7fb618ef82f4 in BN_bin2bn crypto/bn/bn_lib.c:440
#4 0x7fb618fd8933 in EC_GROUP_new_from_ecparameters crypto/ec/ec_asn1.c:618
#5 0x7fb618fd98e8 in EC_GROUP_new_from_ecpkparameters crypto/ec/ec_asn1.c:935
#6 0x7fb618fd9aec in d2i_ECPKParameters crypto/ec/ec_asn1.c:966
#7 0x7fb618fdace9 in d2i_ECParameters crypto/ec/ec_asn1.c:1184
#8 0x7fb618fd1fc7 in eckey_type2param crypto/ec/ec_ameth.c:119
#9 0x7fb618fd57b4 in eckey_pub_decode crypto/ec/ec_ameth.c:165
#10 0x7fb6191a9c62 in x509_pubkey_decode crypto/x509/x_pubkey.c:124
#11 0x7fb6191a9e42 in pubkey_cb crypto/x509/x_pubkey.c:46
#12 0x7fb618eac032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#13 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#14 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#15 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#16 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#17 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#18 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#19 0x7fb618eadd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#20 0x7fb618eade35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#21 0x40310c in FuzzerTestOneInput fuzz/x509.c:33
#22 0x402afb in testfile fuzz/test-corpus.c:182
#23 0x402656 in main fuzz/test-corpus.c:226
#24 0x7fb618551f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
Indirect leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7fb61945309f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fb619092430 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fb618ef7561 in bn_expand_internal crypto/bn/bn_lib.c:280
#3 0x7fb618ef7561 in bn_expand2 crypto/bn/bn_lib.c:304
#4 0x7fb618ef819d in BN_bin2bn crypto/bn/bn_lib.c:454
#5 0x7fb618fd8933 in EC_GROUP_new_from_ecparameters crypto/ec/ec_asn1.c:618
#6 0x7fb618fd98e8 in EC_GROUP_new_from_ecpkparameters crypto/ec/ec_asn1.c:935
#7 0x7fb618fd9aec in d2i_ECPKParameters crypto/ec/ec_asn1.c:966
#8 0x7fb618fdace9 in d2i_ECParameters crypto/ec/ec_asn1.c:1184
#9 0x7fb618fd1fc7 in eckey_type2param crypto/ec/ec_ameth.c:119
#10 0x7fb618fd57b4 in eckey_pub_decode crypto/ec/ec_ameth.c:165
#11 0x7fb6191a9c62 in x509_pubkey_decode crypto/x509/x_pubkey.c:124
#12 0x7fb6191a9e42 in pubkey_cb crypto/x509/x_pubkey.c:46
#13 0x7fb618eac032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#14 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#15 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#16 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#17 0x7fb618eacaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#18 0x7fb618ead288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#19 0x7fb618eab9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#20 0x7fb618eadd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#21 0x7fb618eade35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#22 0x40310c in FuzzerTestOneInput fuzz/x509.c:33
#23 0x402afb in testfile fuzz/test-corpus.c:182
#24 0x402656 in main fuzz/test-corpus.c:226
#25 0x7fb618551f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s).
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/18632)
Fraser Tweedale [Wed, 15 Jun 2022 00:50:57 +0000 (10:50 +1000)]
Fix documentation of BIO_FLAGS_BASE64_NO_NL
Commit 8bfb7506d210841f2ee4eda8afe96441a0e33fa5 updated
`BIO_f_base64(3)` to improve the documentation of the
`BIO_FLAGS_BASE64_NO_NL` flag. In particular, the updated text
states that when this flag is used, all newlines in the input are
ignored. This is incorrect, as the following program proves:
int main(int argc, char **argv) {
BIO *b64 = BIO_new(BIO_f_base64());
if (b64 == NULL) return 1;
BIO_set_flags(b64, BIO_get_flags(b64) | BIO_FLAGS_BASE64_NO_NL);
int in_len = strlen(in_buf);
BIO *in = BIO_new_mem_buf(in_buf, in_len);
if (in == NULL) return 2;
in = BIO_push(b64, in);
unsigned char *out_buf = calloc(in_len, sizeof(unsigned char));
if (out_buf == NULL) return 3;
size_t out_len;
int r = BIO_read_ex(in, out_buf, in_len, &out_len);
printf("rv = %d\n", r);
printf("decoded = %s\n", out_buf);
return 0;
}
```
Update the text of `BIO_f_base64(3)` to clarify that when the flag
is set, the data must be all on one line (with or without a trailing
newline character).
Signed-off-by: Fraser Tweedale <ftweedal@redhat.com> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18568)
Tomas Mraz [Thu, 9 Jun 2022 10:34:55 +0000 (12:34 +0200)]
Always end BN_mod_exp_mont_consttime with normal Montgomery reduction.
This partially fixes a bug where, on x86_64, BN_mod_exp_mont_consttime
would sometimes return m, the modulus, when it should have returned
zero. Thanks to Guido Vranken for reporting it. It is only a partial fix
because the same bug also exists in the "rsaz" codepath.
The bug only affects zero outputs (with non-zero inputs), so we believe
it has no security impact on our cryptographic functions.
The fx is to delete lowercase bn_from_montgomery altogether, and have the
mont5 path use the same BN_from_montgomery ending as the non-mont5 path.
This only impacts the final step of the whole exponentiation and has no
measurable perf impact.
Matt Caswell [Thu, 9 Jun 2022 15:57:30 +0000 (16:57 +0100)]
Fix a crash in X509v3_asid_subset()
If the asnum or rdi fields are NULL and the ASIdentifiers are otherwise
subsets then this will result in a crash. Of note is that rdi will usually
be NULL.
Reported by Theo Buehler (@botovq)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Yang <kaishen.yy@antfin.com> Reviewed-by: Todd Short <todd.short@me.com>
(Merged from https://github.com/openssl/openssl/pull/18514)
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7fd5d8b8309f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fd5d87c2430 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fd5d889501f in OPENSSL_sk_new_reserve crypto/stack/stack.c:209
#3 0x7fd5d85dcbc3 in sk_ASN1_VALUE_new_null include/openssl/asn1t.h:928
#4 0x7fd5d85dcbc3 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:577
#5 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#6 0x7fd5d85db104 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:178
#7 0x7fd5d85ddd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#8 0x7fd5d85dde35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#9 0x7fd5d88f86d9 in X509V3_EXT_d2i crypto/x509v3/v3_lib.c:142
#10 0x7fd5d88d6d3c in crl_set_issuers crypto/x509/x_crl.c:97
#11 0x7fd5d88d6d3c in crl_cb crypto/x509/x_crl.c:246
#12 0x7fd5d85dc032 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:432
#13 0x7fd5d85dcaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#14 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#15 0x7fd5d85db2b5 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:259
#16 0x7fd5d85dc813 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:611
#17 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#18 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#19 0x7fd5d85dca28 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:633
#20 0x7fd5d85dd288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#21 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#22 0x7fd5d85dcaf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#23 0x7fd5d85dd7d3 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:494
#24 0x7fd5d85db9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#25 0x7fd5d85ddd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#26 0x7fd5d85dde35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#27 0x7fd5d85a77e0 in ASN1_item_d2i_bio crypto/asn1/a_d2i_fp.c:69
#28 0x402845 in FuzzerTestOneInput fuzz/cms.c:43
#29 0x402bbb in testfile fuzz/test-corpus.c:182
#30 0x402626 in main fuzz/test-corpus.c:226
#31 0x7fd5d7c81f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
SUMMARY: AddressSanitizer: 32 byte(s) leaked in 1 allocation(s).
Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18391)
Bernd Edlinger [Sun, 22 May 2022 18:12:56 +0000 (20:12 +0200)]
Fix a crash in ssl_security_cert_chain
Prior to the crash there is an out of memory error
in X509_verify_cert which makes the chain NULL or
empty. The error is ignored by ssl_add_cert_chain,
and ssl_security_cert_chain crashes due to the
unchecked null pointer.
This is reproducible with my error injection patch.
The test vector has been validated on the 1.1.1 branch
but the issue is of course identical in all branches.
$ ERROR_INJECT=1652848273 ../util/shlib_wrap.sh ./server-test ./corpora/server/47c8e933c4ec66fa3c309422283dfe0f31aafae8# ./corpora/server/47c8e933c4ec66fa3c309422283dfe0f31aafae8
#0 0x7f3a8f766eba in __sanitizer_print_stack_trace ../../../../gcc-trunk/libsanitizer/asan/asan_stack.cpp:87
#1 0x403ba4 in my_malloc fuzz/test-corpus.c:114
#2 0x7f3a8f39a430 in CRYPTO_zalloc crypto/mem.c:230
#3 0x7f3a8f46bd3b in sk_reserve crypto/stack/stack.c:180
#4 0x7f3a8f46bd3b in OPENSSL_sk_insert crypto/stack/stack.c:242
#5 0x7f3a8f4a4fd8 in sk_X509_push include/openssl/x509.h:99
#6 0x7f3a8f4a4fd8 in X509_verify_cert crypto/x509/x509_vfy.c:286
#7 0x7f3a8fed726e in ssl_add_cert_chain ssl/statem/statem_lib.c:959
#8 0x7f3a8fed726e in ssl3_output_cert_chain ssl/statem/statem_lib.c:1015
#9 0x7f3a8fee1c50 in tls_construct_server_certificate ssl/statem/statem_srvr.c:3812
#10 0x7f3a8feb8b0a in write_state_machine ssl/statem/statem.c:843
#11 0x7f3a8feb8b0a in state_machine ssl/statem/statem.c:443
#12 0x7f3a8fe84b3f in SSL_do_handshake ssl/ssl_lib.c:3718
#13 0x403202 in FuzzerTestOneInput fuzz/server.c:740
#14 0x40371b in testfile fuzz/test-corpus.c:182
#15 0x402856 in main fuzz/test-corpus.c:226
#16 0x7f3a8e859f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#17 0x402936 (/home/ed/OPC/openssl/fuzz/server-test+0x402936)
AddressSanitizer:DEADLYSIGNAL
=================================================================
==8400==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000158 (pc 0x7f3a8f4d822f bp 0x7ffc39b76190 sp 0x7ffc39b760a0 T0)
==8400==The signal is caused by a READ memory access.
==8400==Hint: address points to the zero page.
#0 0x7f3a8f4d822f in x509v3_cache_extensions crypto/x509v3/v3_purp.c:386
#1 0x7f3a8f4d9d3a in X509_check_purpose crypto/x509v3/v3_purp.c:84
#2 0x7f3a8f4da02a in X509_get_extension_flags crypto/x509v3/v3_purp.c:921
#3 0x7f3a8feff7d2 in ssl_security_cert_sig ssl/t1_lib.c:2518
#4 0x7f3a8feff7d2 in ssl_security_cert ssl/t1_lib.c:2542
#5 0x7f3a8feffa03 in ssl_security_cert_chain ssl/t1_lib.c:2562
#6 0x7f3a8fed728d in ssl_add_cert_chain ssl/statem/statem_lib.c:963
#7 0x7f3a8fed728d in ssl3_output_cert_chain ssl/statem/statem_lib.c:1015
#8 0x7f3a8fee1c50 in tls_construct_server_certificate ssl/statem/statem_srvr.c:3812
#9 0x7f3a8feb8b0a in write_state_machine ssl/statem/statem.c:843
#10 0x7f3a8feb8b0a in state_machine ssl/statem/statem.c:443
#11 0x7f3a8fe84b3f in SSL_do_handshake ssl/ssl_lib.c:3718
#12 0x403202 in FuzzerTestOneInput fuzz/server.c:740
#13 0x40371b in testfile fuzz/test-corpus.c:182
#14 0x402856 in main fuzz/test-corpus.c:226
#15 0x7f3a8e859f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#16 0x402936 (/home/ed/OPC/openssl/fuzz/server-test+0x402936)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV crypto/x509v3/v3_purp.c:386 in x509v3_cache_extensions
==8400==ABORTING
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18376)
Direct leak of 268 byte(s) in 1 object(s) allocated from:
#0 0x7fd485a5dc3e in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:163
#1 0x7fd484d2eb9b in BUF_MEM_grow crypto/buffer/buffer.c:97
#2 0x7fd4850b2913 in X509_NAME_oneline crypto/x509/x509_obj.c:43
#3 0x7fd4850a982f in X509_issuer_and_serial_hash crypto/x509/x509_cmp.c:41
#4 0x55c12d268951 in FuzzerTestOneInput fuzz/x509.c:44
#5 0x55c12d268239 in testfile fuzz/test-corpus.c:182
#6 0x55c12d267c7f in main fuzz/test-corpus.c:226
#7 0x7fd483a42082 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: 268 byte(s) leaked in 1 allocation(s).
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18370)
Bernd Edlinger [Fri, 20 May 2022 14:54:41 +0000 (16:54 +0200)]
Fix undefined behaviour in EC_GROUP_new_from_ecparameters
This happens for instance with
fuzz/corpora/asn1/65cf44e85614c62f10cf3b7a7184c26293a19e4a
and causes the OPENSSL_malloc below to choke on the
zero length allocation request.
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18363)
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7fdd2a6bb09f in __interceptor_malloc ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fdd2a2fa430 in CRYPTO_zalloc crypto/mem.c:230
#2 0x7fdd2a15df11 in BN_new crypto/bn/bn_lib.c:246
#3 0x7fdd2a15df88 in BN_secure_new crypto/bn/bn_lib.c:257
#4 0x7fdd2a247390 in ec_key_simple_oct2priv crypto/ec/ec_key.c:655
#5 0x7fdd2a241fc5 in d2i_ECPrivateKey crypto/ec/ec_asn1.c:1030
#6 0x7fdd2a23dac5 in old_ec_priv_decode crypto/ec/ec_ameth.c:463
#7 0x7fdd2a109db7 in d2i_PrivateKey crypto/asn1/d2i_pr.c:46
#8 0x7fdd2a33ab16 in PEM_read_bio_PrivateKey crypto/pem/pem_pkey.c:84
#9 0x7fdd2a3330b6 in PEM_read_bio_ECPrivateKey crypto/pem/pem_all.c:151
#10 0x402dba in FuzzerTestOneInput fuzz/server.c:592
#11 0x40370b in testfile fuzz/test-corpus.c:182
#12 0x402846 in main fuzz/test-corpus.c:226
#13 0x7fdd297b9f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
SUMMARY: AddressSanitizer: 24 byte(s) leaked in 1 allocation(s).
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18361)
Bernd Edlinger [Fri, 20 May 2022 06:02:47 +0000 (08:02 +0200)]
Fix a crash in asn1_item_embed_new
This happens usually if an template object is created
and there is an out of memory error before the ASN1_OP_NEW_POST
method is called, but asn1_item_embed_free calls now the
ASN1_OP_FREE_POST which may crash because the object is not
properly initialized. Apparently that is only an issue with
the ASN1_OP_FREE_POST handling of crypot/x509/x_crl.c, which
ought to be tolerant to incomplete initialized objects.
The error can be reproduced with the reproducible error injection patch:
$ ERROR_INJECT=1652890550 ../util/shlib_wrap.sh ./asn1-test ./corpora/asn1/0ff17293911f54d1538b9896563a4048d67d9ee4
#0 0x7faae9dbeeba in __sanitizer_print_stack_trace ../../../../gcc-trunk/libsanitizer/asan/asan_stack.cpp:87
#1 0x408dc4 in my_malloc fuzz/test-corpus.c:114
#2 0x7faae99f2430 in CRYPTO_zalloc crypto/mem.c:230
#3 0x7faae97f09e5 in ASN1_STRING_type_new crypto/asn1/asn1_lib.c:341
#4 0x7faae98118f7 in asn1_primitive_new crypto/asn1/tasn_new.c:318
#5 0x7faae9812401 in asn1_item_embed_new crypto/asn1/tasn_new.c:78
#6 0x7faae9812401 in asn1_template_new crypto/asn1/tasn_new.c:240
#7 0x7faae9812315 in asn1_item_embed_new crypto/asn1/tasn_new.c:137
#8 0x7faae9812315 in asn1_template_new crypto/asn1/tasn_new.c:240
#9 0x7faae9812a54 in asn1_item_embed_new crypto/asn1/tasn_new.c:137
#10 0x7faae9812a54 in ASN1_item_ex_new crypto/asn1/tasn_new.c:39
#11 0x7faae980be51 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:325
#12 0x7faae980c813 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:611
#13 0x7faae980d288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#14 0x7faae980b9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#15 0x7faae980caf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#16 0x7faae980d7d3 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:494
#17 0x7faae980b9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#18 0x7faae980dd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#19 0x7faae980de35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#20 0x40712c in FuzzerTestOneInput fuzz/asn1.c:301
#21 0x40893b in testfile fuzz/test-corpus.c:182
#22 0x406b86 in main fuzz/test-corpus.c:226
#23 0x7faae8eb1f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
AddressSanitizer:DEADLYSIGNAL
=================================================================
==1194==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7faae9b0625f bp 0x7fffffe41a00 sp 0x7fffffe41920 T0)
==1194==The signal is caused by a READ memory access.
==1194==Hint: address points to the zero page.
#0 0x7faae9b0625f in crl_cb crypto/x509/x_crl.c:258
#1 0x7faae9811255 in asn1_item_embed_free crypto/asn1/tasn_fre.c:113
#2 0x7faae9812a65 in asn1_item_embed_new crypto/asn1/tasn_new.c:150
#3 0x7faae9812a65 in ASN1_item_ex_new crypto/asn1/tasn_new.c:39
#4 0x7faae980be51 in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:325
#5 0x7faae980c813 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:611
#6 0x7faae980d288 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:518
#7 0x7faae980b9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#8 0x7faae980caf5 in asn1_template_noexp_d2i crypto/asn1/tasn_dec.c:643
#9 0x7faae980d7d3 in asn1_template_ex_d2i crypto/asn1/tasn_dec.c:494
#10 0x7faae980b9ce in asn1_item_embed_d2i crypto/asn1/tasn_dec.c:382
#11 0x7faae980dd1f in ASN1_item_ex_d2i crypto/asn1/tasn_dec.c:124
#12 0x7faae980de35 in ASN1_item_d2i crypto/asn1/tasn_dec.c:114
#13 0x40712c in FuzzerTestOneInput fuzz/asn1.c:301
#14 0x40893b in testfile fuzz/test-corpus.c:182
#15 0x406b86 in main fuzz/test-corpus.c:226
#16 0x7faae8eb1f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV crypto/x509/x_crl.c:258 in crl_cb
==1194==ABORTING
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18360)
Don't Overflow when printing Thawte Strong Extranet Version
When printing human readable info on the Thawte Strong Extranet extension
the version number could overflow if the version number == LONG_MAX. This
is undefined behaviour.
Issue found by OSSFuzz.
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/13452)
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18347)
Daniel Fiala [Tue, 10 May 2022 08:46:37 +0000 (08:46 +0000)]
s_serve: Report an error if init-connection fails without an attempt to read.
Fixes: openssl#18047. Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18283)
Fix leakage when the cacheline is 32-bytes in CBC_MAC_ROTATE_IN_PLACE
rotated_mac is a 64-byte aligned buffer of size 64 and rotate_offset is secret.
Consider a weaker leakage model(CL) where only cacheline base address is leaked,
i.e address/32 for 32-byte cacheline(CL32).
Previous code used to perform two loads
1. rotated_mac[rotate_offset ^ 32] and
2. rotated_mac[rotate_offset++]
which would leak 2q + 1, 2q for 0 <= rotate_offset < 32
and 2q, 2q + 1 for 32 <= rotate_offset < 64
The proposed fix performs load operations which will always leak 2q, 2q + 1 and
selects the appropriate value in constant-time.
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18050)
Allan Jude [Fri, 19 Nov 2021 19:06:52 +0000 (19:06 +0000)]
1_1_1-stable: Detect arm64-*-*bsd and enable assembly optimizations
Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com> Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/17085)