openbsd/src/lib/libcrypto/x509, branch libressl-v3.2.3 A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v3.2.3 2020-12-08T15:08:47+00:00 Fix a NULL dereference in GENERAL_NAME_cmp() 2020-12-08T15:08:47+00:00 tb 2020-12-08T15:08:47+00:00 urn:sha1:267ac14fa6781b6553b05a6d8dcdf99eaacc0edf 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 this is errata/6.8/008_asn1.patch.sig Ensure leaf is set up on X509_STORE_CTX before verification. 2020-09-26T15:44:06+00:00 jsing 2020-09-26T15:44:06+00:00 urn:sha1:4e8347390553060ef9ddb7e486d3c945d2af54ab Previously the leaf certificate was only being set up on the X509_STORE_CTX after two verification steps were performed, however at least one of those steps could result in the verification callback being triggered and existing code breaking. Issue noticed by Raf Czlonka when attempting to connect to talk.google.com using profanity (which does not set SNI and ends up receiving an invalid certificate). ok beck@ deraadt@ tb@ jumping into the x509 fray with a bunch of whitespace repair 2020-09-26T02:06:28+00:00 deraadt 2020-09-26T02:06:28+00:00 urn:sha1:3e6655fb0b20e8ae2d4546bab15df8fe320eec75 Ensure chain is set on the X509_STORE_CTX before triggering callback. 2020-09-23T18:20:16+00:00 jsing 2020-09-23T18:20:16+00:00 urn:sha1:75f522291d5ee57ddc9fa504c8c61e280dacfbaf Various software expects the previous behaviour where the certificate chain is available on the X509_STORE_CTX when the verify callback is triggered. Issue hit by bket@ with lastpass-cli which has built in certificate pinning that is checked via the verify callback. Fix confirmed by bket@. ok beck@ Fix some line wrapping and other whitespace issues. 2020-09-21T05:41:43+00:00 tb 2020-09-21T05:41:43+00:00 urn:sha1:6ee00092aca7120fdc6c535595cc4d55cda3e05d No change in the generated assembly on amd64. Move freeing and zeroing up to right after the while loop. 2020-09-21T05:20:20+00:00 tb 2020-09-21T05:20:20+00:00 urn:sha1:e61b320e8d19af9d30c2c97c456cf47cf857c241 Requested by jsing Avoid memleak caused by shadowing 2020-09-20T19:13:06+00:00 tb 2020-09-20T19:13:06+00:00 urn:sha1:997a143ecd162f797e525fdea4a0e42c1c73c939 The outer scope in x509_constraints_extract_names() contains a vname variable which will be freed on error, but an inner scope contains another vname that won't be freed, e.g., if x509_constraints_names_add fails. Found by llvm scan-build. ok beck KNF/whitespace nits 2020-09-20T18:32:33+00:00 tb 2020-09-20T18:32:33+00:00 urn:sha1:d1b6fcd5204171614ffca34c18b320cbdd1650b1 Correct a 1 byte read overflow in x509_contraints_uri and add 2020-09-20T18:22:31+00:00 beck 2020-09-20T18:22:31+00:00 urn:sha1:407345d49b1ca886ab4bc7e429c61fb07a7eb964 regress to catch it in the future. found by Guido Vranken's cryptofuzzer ok tb@ Fix a memory leak in x509_constraints_extract_names 2020-09-20T03:19:52+00:00 tb 2020-09-20T03:19:52+00:00 urn:sha1:fb6f37b43e95953a3e7180f1c3cc4fbc1e9e3a16 If the default path of the switch is taken, vname will not be added to the names list and will leak when it is set to NULL. Simplify the logic by eliminating the add Boolean. Instead, free and zero vname in the default case and continue the while loop directly. At the bottom of the switch, add vname to the names list unconditionally zero it out since it's now owned by names. Found by Guido Vranken's cryptofuzzer ok beck