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-05T19:34:57+00:00 tb 2020-12-05T19:34:57+00:00 urn:sha1:e15b4af220e429099aba832b31f097b2916d19e8 ok jsing kn 2020-12-05T19:33:38+00:00 tb 2020-12-05T19:33:38+00:00 urn:sha1:8c0f6308a96a26238a44856da0cb53a3cb54bbf2 ok jsing kn 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-12-01T07:46:02+00:00 tb 2020-12-01T07:46:02+00:00 urn:sha1:d8448fdca0c2c2d2c222f03a47902325615a5996 The method unification broke an API promise of SSL_is_server(). According to the documentation, calling SSL_is_server() on SSL objects constructed from generic and server methods would result in 1 even before any call to SSL_set_accept_state(). This means the information needs to be available when SSL_new() is called, so must come from the method itself. Prior to the method unification, s->server would be set to 0 or 1 in SSL_new() depending on whether the accept method was undefined or not. Instead, introduce a flag to the internal structs to distinguish client methods from server and generic methods and copy that flag to s->server in SSL_new(). This problem was reported to otto due to breakage of DoH in net/dnsdist. The reason for this is that www/h2o relies on SSL_is_server() to decide whether to call SSL_accept() or SSL_connect(). Thus, the h2o server would end up responding to a ClientHello with another ClientHello, which results in a handshake failure. The bandaid applied to www/h2o can be removed once this fix has made it into snaps. No other breakage is known. This commit brings back only about half of the duplication removed in the method unification, so is preferable to a full revert. ok jsing 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-23T15:42:11+00:00 otto 2020-11-23T15:42:11+00:00 urn:sha1:c77e1ca5ca01ce42fde26161844ab04c5c3ae055 2020-11-20T08:08:02+00:00 tb 2020-11-20T08:08:02+00:00 urn:sha1:0068cc3650e1a212d865b7843ac3d0f02acce643