A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v3.3.1 2020-12-08T17:39:06+00:00 2020-12-08T17:39:06+00:00 bcook 2020-12-08T17:39:06+00:00 urn:sha1:3a8e5b1810653b07037a5ff1e5b46554bb430ac2 2020-12-08T15:06:42+00:00 tb 2020-12-08T15:06:42+00:00 urn: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 2020-12-04T08:55:30+00:00 tb 2020-12-04T08:55:30+00:00 urn:sha1:19beb136cce42fbe56d004577d27ddc0ca69f793 Bad API design makes it possible to set an EC_KEY public key to a point not on the curve. As a consequence, it was possible to have bogus ECDSA signatures validated. In practice, all software uses either EC_POINT_oct2point*() to unmarshal public keys or issues a call to EC_KEY_check_key() after setting it. This way, a point on curve check is performed and the problem is mitigated. In OpenSSL commit 1e2012b7ff4a5f12273446b281775faa5c8a1858, Emilia Kasper moved the point-on-curve check from EC_POINT_oct2point to EC_POINT_set_affine_coordinates_*, which results in more checking. In addition to this commit, we also check in the currently unused codepath of a user set callback for setting compressed coordinates, just in case this will be used at some point in the future. The documentation of EC_KEY_check_key() is very vague on what it checks and when checks are needed. It could certainly be improved a lot. It's also strange that EC_KEY_set_key() performs no checks, while EC_KEY_set_public_key_affine_coordinates() implicitly calls EC_KEY_check_key(). It's a mess. Issue found and reported by Guido Vranken who also tested an earlier version of this fix. ok jsing 2020-12-03T22:47:22+00:00 jmc 2020-12-03T22:47:22+00:00 urn:sha1:bf90c7348aa11c405e8d6a2e0bceeb937623d4b8 2020-11-25T21:17:52+00:00 tb 2020-11-25T21:17:52+00:00 urn: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 2020-11-18T17:54:46+00:00 tb 2020-11-18T17:54:46+00:00 urn: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 2020-11-18T17:40:42+00:00 tb 2020-11-18T17:40:42+00:00 urn: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 2020-11-18T17:13:55+00:00 tb 2020-11-18T17:13:55+00:00 urn:sha1:644cb0c3bf194db22125d9f1f2bb4fbdad279d65 2020-11-18T17:08:59+00:00 tb 2020-11-18T17:08:59+00:00 urn:sha1:3bc85c50efd5da6e970a3a4b0bf1d312386c6327 a few lines after. stylistic nit from jsing 2020-11-18T17:00:59+00:00 tb 2020-11-18T17:00:59+00:00 urn:sha1:05555ab1add6e7a31798831da9ff788048d1b3cf