Package: openssl / 1.1.1d-0+deb10u6

Metadata

Package Version Patches format
openssl 1.1.1d-0+deb10u6 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
debian targets.patch | (download)

Configurations/20-debian.conf | 192 192 + 0 - 0 !
1 file changed, 192 insertions(+)

 debian-targets


man section.patch | (download)

Configurations/unix-Makefile.tmpl | 6 4 + 2 - 0 !
util/process_docs.pl | 3 2 + 1 - 0 !
2 files changed, 6 insertions(+), 3 deletions(-)

 man-section


no symbolic.patch | (download)

Configurations/shared-info.pl | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 no-symbolic


pic.patch | (download)

crypto/des/asm/desboth.pl | 17 14 + 3 - 0 !
crypto/perlasm/cbc.pl | 24 20 + 4 - 0 !
crypto/perlasm/x86gas.pl | 16 16 + 0 - 0 !
crypto/x86cpuid.pl | 10 5 + 5 - 0 !
4 files changed, 55 insertions(+), 12 deletions(-)

 pic


c_rehash compat.patch | (download)

tools/c_rehash.in | 20 14 + 6 - 0 !
1 file changed, 14 insertions(+), 6 deletions(-)

 [patch] also create old hash for compatibility


Set systemwide default settings for libssl users.patch | (download)

apps/openssl.cnf | 12 12 + 0 - 0 !
1 file changed, 12 insertions(+)

 set systemwide default settings for libssl users

This config change enforeces a TLS1.2 protocol version as minimum. It
can be overwritten by the system administrator.

It also changes the default security level from 1 to 2, moving from the 80 bit
security level to the 112 bit security level.

Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>

Define AESNI_ASM if AESNI assembler is included and use i.patch | (download)

Configure | 1 1 + 0 - 0 !
crypto/evp/e_aes_cbc_hmac_sha1.c | 2 1 + 1 - 0 !
crypto/evp/e_aes_cbc_hmac_sha256.c | 4 2 + 2 - 0 !
3 files changed, 4 insertions(+), 3 deletions(-)

 define aesni_asm if aesni assembler is included, and use it

Because we have cases where basic assembler support isn't present, but
AESNI asssembler support is, we need a separate macro that indicates
that, and use it.

Add test for CVE 2020 1967.patch | (download)

test/recipes/70-test_sslsigalgs.t | 66 64 + 2 - 0 !
1 file changed, 64 insertions(+), 2 deletions(-)

 add test for cve-2020-1967

Add to test_sslsigalgs a TLSProxy test that injects a
"signature_algorithms_cert" extension that contains an unallocated
codepoint.

The test currently fails, since s_server segfaults instead of
ignoring the unrecognized value.

Since "signature_algorithms" and "signature_algorithms_cert" are very
similar, also add the analogous test for "signature_algorithms".

[bigeasy: + 2x "fixup! Add test for CVE-2020-1967"]

Fix NULL dereference in SSL_check_chain for TLS 1.3.patch | (download)

ssl/t1_lib.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 fix null dereference in ssl_check_chain() for tls 1.3

In the tls1_check_sig_alg() helper function, we loop through the list of
"signature_algorithms_cert" values received from the client and attempt
to look up each one in turn in our internal table that maps wire
codepoint to string-form name, digest and/or signature NID, etc., in
order to compare the signature scheme from the peer's list against what
is used to sign the certificates in the certificate chain we're
checking.  Unfortunately, when the peer sends a value that we don't
support, the lookup returns NULL, but we unconditionally dereference the
lookup result for the comparison, leading to an application crash
triggerable by an unauthenticated client.

Since we will not be able to say anything about algorithms we don't
recognize, treat NULL return from lookup as "does not match".

We currently only apply the "signature_algorithm_cert" checks on TLS 1.3
connections, so previous TLS versions are unaffected.  SSL_check_chain()
is not called directly from libssl, but may be used by the application
inside a callback (e.g., client_hello or cert callback) to verify that a
candidate certificate chain will be acceptable to the client.

CVE-2020-1967

DirectoryString is a CHOICE type and therefore uses expli.patch | (download)

crypto/x509v3/v3_genn.c | 5 3 + 2 - 0 !
1 file changed, 3 insertions(+), 2 deletions(-)

 directorystring is a choice type and therefore uses explicit tagging

EDIPartyName has 2 fields that use a DirectoryString. However they were
marked as implicit tagging - which is not correct for a CHOICE type.

Additionally the partyName field was marked as Optional when, according to
RFC5280 it is not.

Many thanks to github user @filipnavara for reporting this issue. Also to
David Benjamin from Google who independently identified and reported it.

Fixes #6859

Correctly compare EdiPartyName in GENERAL_NAME_cmp.patch | (download)

crypto/x509v3/v3_genn.c | 45 42 + 3 - 0 !
1 file changed, 42 insertions(+), 3 deletions(-)

 correctly compare edipartyname in general_name_cmp()

If a GENERAL_NAME field contained EdiPartyName data then it was
incorrectly being handled as type "other". This could lead to a
segmentation fault.

Many thanks to David Benjamin from Google for reporting this issue.

CVE-2020-1971

Check that multi strings CHOICE types don t use implicit .patch | (download)

crypto/asn1/asn1_err.c | 1 1 + 0 - 0 !
crypto/asn1/tasn_dec.c | 19 19 + 0 - 0 !
crypto/err/openssl.txt | 1 1 + 0 - 0 !
include/openssl/asn1err.h | 1 1 + 0 - 0 !
4 files changed, 22 insertions(+)

 check that multi-strings/choice types don't use implicit tagging

It never makes sense for multi-string or CHOICE types to use implicit
tagging since the content would be ambiguous. It is an error in the
template if this ever happens. If we detect it we should stop parsing.

Thanks to David Benjamin from Google for reporting this issue.

Complain if we are attempting to encode with an invalid A.patch | (download)

crypto/asn1/asn1_err.c | 3 2 + 1 - 0 !
crypto/asn1/tasn_enc.c | 16 16 + 0 - 0 !
crypto/err/openssl.txt | 1 1 + 0 - 0 !
include/openssl/asn1err.h | 7 3 + 4 - 0 !
4 files changed, 22 insertions(+), 5 deletions(-)

 complain if we are attempting to encode with an invalid asn.1
 template

It never makes sense for multi-string or CHOICE types to have implicit
tagging. If we have a template that uses the in this way then we
should immediately fail.

Thanks to David Benjamin from Google for reporting this issue.

Add a test for GENERAL_NAME_cmp.patch | (download)

test/v3nametest.c | 344 344 + 0 - 0 !
1 file changed, 344 insertions(+)

 add a test for general_name_cmp

Based on a boringssl test contributed by David Benjamin

Add a test for encoding decoding using an invalid ASN.1 T.patch | (download)

test/asn1_decode_test.c | 36 36 + 0 - 0 !
test/asn1_encode_test.c | 33 33 + 0 - 0 !
2 files changed, 69 insertions(+)

 add a test for encoding/decoding using an invalid asn.1 template

If you have a CHOICE type that it must use explicit tagging - otherwise
the template is invalid. We add tests for this.

Fix Null pointer deref in X509_issuer_and_serial_hash.patch | (download)

crypto/x509/x509_cmp.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 fix null pointer deref in x509_issuer_and_serial_hash()

The OpenSSL public API function X509_issuer_and_serial_hash() attempts
to create a unique hash value based on the issuer and serial number data
contained within an X509 certificate. However it fails to correctly
handle any errors that may occur while parsing the issuer field (which
might occur if the issuer field is maliciously constructed). This may
subsequently result in a NULL pointer deref and a crash leading to a
potential denial of service attack.

The function X509_issuer_and_serial_hash() is never directly called by
OpenSSL itself so applications are only vulnerable if they use this
function directly and they use it on certificates that may have been
obtained from untrusted sources.

CVE-2021-23841

Don t overflow the output length in EVP_CipherUpdate call.patch | (download)

crypto/err/openssl.txt | 3 2 + 1 - 0 !
crypto/evp/evp_enc.c | 27 27 + 0 - 0 !
crypto/evp/evp_err.c | 4 3 + 1 - 0 !
include/openssl/evperr.h | 7 3 + 4 - 0 !
4 files changed, 35 insertions(+), 6 deletions(-)

 don't overflow the output length in evp_cipherupdate calls

CVE-2021-23840

Fix an overflow bug in rsaz_512_sqr.patch | (download)

crypto/bn/asm/rsaz-x86_64.pl | 387 200 + 187 - 0 !
1 file changed, 200 insertions(+), 187 deletions(-)

 fix an overflow bug in rsaz_512_sqr

There is an overflow bug in the x64_64 Montgomery squaring procedure used in
exponentiation with 512-bit moduli. No EC algorithms are affected. Analysis
suggests that attacks against 2-prime RSA1024, 3-prime RSA1536, and DSA1024 as a
Teach TLSProxy how to encrypt TLSv1.2 ETM records.patch | (download)

util/perl/TLSProxy/Message.pm | 37 30 + 7 - 0 !
1 file changed, 30 insertions(+), 7 deletions(-)

 teach tlsproxy how to encrypt <= tlsv1.2 etm records

Previously TLSProxy only knew how to "repack" messages for TLSv1.3.
Most of the handshake in <= TLSv1.2 is unencrypted so this hasn't been
too much of restriction. However we now want to modify reneg handshakes
which are encrypted so we need to add that capability.

Add a test for CVE 2021 3449.patch | (download)

test/recipes/70-test_renegotiation.t | 36 35 + 1 - 0 !
1 file changed, 35 insertions(+), 1 deletion(-)

 add a test for cve-2021-3449

We perform a reneg handshake, where the second ClientHello drops the
sig_algs extension. It must also contain cert_sig_algs for the test to
work.

ssl sigalg extension fix NULL pointer dereference.patch | (download)

ssl/statem/extensions.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 ssl sigalg extension: fix null pointer dereference
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

As the variable peer_sigalgslen is not cleared on ssl rehandshake, it's
possible to crash an openssl tls secured server remotely by sending a
manipulated hello message in a rehandshake.

On such a manipulated rehandshake, tls1_set_shared_sigalgs() calls
tls12_shared_sigalgs() with the peer_sigalgslen of the previous
handshake, while the peer_sigalgs has been freed.
As a result tls12_shared_sigalgs() walks over the available
peer_sigalgs and tries to access data of a NULL pointer.

This issue was introduced by c589c34e61 (Add support for the TLS 1.3
signature_algorithms_cert extension, 2018-01-11).

Signed-off-by: Peter Kästle <peter.kaestle@nokia.com>
Signed-off-by: Samuel Sapalski <samuel.sapalski@nokia.com>

CVE-2021-3449

CLA: trivial

Ensure buffer length pairs are always in sync.patch | (download)

ssl/s3_lib.c | 5 4 + 1 - 0 !
ssl/ssl_lib.c | 14 11 + 3 - 0 !
ssl/statem/extensions.c | 1 1 + 0 - 0 !
ssl/statem/extensions_clnt.c | 14 12 + 2 - 0 !
ssl/statem/statem_clnt.c | 7 6 + 1 - 0 !
ssl/statem/statem_srvr.c | 17 14 + 3 - 0 !
6 files changed, 48 insertions(+), 10 deletions(-)

 ensure buffer/length pairs are always in sync

Following on from CVE-2021-3449 which was caused by a non-zero length
associated with a NULL buffer, other buffer/length pairs are updated to
ensure that they too are always in sync.