openbsd/src/lib/libcrypto/x509, branch libressl-v3.3.1A mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=libressl-v3.3.12020-12-08T15:06:42+00:00Fix a NULL dereference in GENERAL_NAME_cmp()2020-12-08T15:06:42+00:00tb2020-12-08T15:06:42+00:00urn:sha1:9b6213a4c1c3792c23b8d5da5d4d7ef1cae15e50
Comparing two GENERAL_NAME structures containing an EDIPARTYNAME can lead
to a crash. This enables a denial of service attack for an attacker who can
control both sides of the comparison.
Issue reported to OpenSSL on Nov 9 by David Benjamin.
OpenSSL shared the information with us on Dec 1st.
Fix from Matt Caswell (OpenSSL) with a few small tweaks.
ok jsing
Avoid undefined behavior due to memcpy(NULL, NULL, 0)2020-11-25T21:17:52+00:00tb2020-11-25T21:17:52+00:00urn:sha1:143c67355191b6f6ff2cfccb3f876320138a37fb
This happens if name->der_len == 0. Since we already have a length
check, we can malloc and memcpy inside the conditional. This also
makes the code easier to read.
agreement from millert
ok jsing
Plug leak in x509_verify_chain_dup()2020-11-18T17:54:46+00:00tb2020-11-18T17:54:46+00:00urn:sha1:d7ea65d1de4c5d0528a68eb9b33a6ef17ca79f14
x509_verify_chain_new() allocates a few members of a certificate chain:
an empty stack of certificates, a list of errors encountered while
validating the chain, and a list of name constraints. The function to
copy a chain would allocate a new chain using x509_verify_chain_new()
and then clobber its members by copies of the old chain. Fix this by
replacing x509_verify_chain_new() with calloc().
Found by review while investigating the report by Hanno Zysik who
found the same leak using valgrind. This is a cleaner version of
my initial fix from jsing.
ok jsing
Plug a big memory leak in the new validator2020-11-18T17:40:42+00:00tb2020-11-18T17:40:42+00:00urn:sha1:fa7f97be6a425fa454c92d146ea0a205a46da2a0
The legacy validator would only call x509_vfy_check_policy() once at
the very end after cobbling together a chain. Therefore it didn't
matter that X509_policy_check() always allocates a new tree on top of
the one that might have been passed in. This is in stark contrast to
other, similar APIs in this code base. The new validator calls this
function several times over while building its chains. This adds up
to a sizable leak in the new validator.
Reported with a reproducer by Hanno Zysik on github, who also bisected
this to the commit enabling the new validator.
Narrowed down to x509_vfy_check_policy() by jsing.
We simultaenously came up with a functionally identical fix.
ok jsing
zap ugly empty line before closing brace2020-11-18T17:13:55+00:00tb2020-11-18T17:13:55+00:00urn:sha1:644cb0c3bf194db22125d9f1f2bb4fbdad279d65Move freeing of the verify context to its natural place instead of2020-11-18T17:08:59+00:00tb2020-11-18T17:08:59+00:00urn:sha1:3bc85c50efd5da6e970a3a4b0bf1d312386c6327
a few lines after.
stylistic nit from jsing
KNF (whitespace)2020-11-18T17:00:59+00:00tb2020-11-18T17:00:59+00:00urn:sha1:05555ab1add6e7a31798831da9ff788048d1b3cfUse X509_V_OK instead of 0.2020-11-16T17:43:37+00:00jsing2020-11-16T17:43:37+00:00urn:sha1:405976d31ae6b14d18567c95b7b569a4f840959c
ok beck@ tb@
Add back an X509_STORE_CTX error code assignment.2020-11-16T17:42:35+00:00jsing2020-11-16T17:42:35+00:00urn:sha1:6d683ad99d2d002b7d27f3685fa75523eca88ce3
This was inadvertently removed in r1.19.
Spotted by tb@
ok beck@ tb@
Return the specific failure for a "self signed certificate" in the chain2020-11-15T17:54:49+00:00beck2020-11-15T17:54:49+00:00urn:sha1:80b086a4acc51fd3fe6aa757d59578dbe416f61d
in order to be compatible with the openssl error craziness in the legacy
verifier case.
This will fix a regress problem noticed by znc
ok tb@