A mirror of https://github.com/libressl/openbsd.git https://git.lua4.win/openbsd/atom?h=libressl-v3.3.5 2021-08-20T19:54:59+00:00 2021-08-20T19:54:59+00:00 benno 2021-08-20T19:54:59+00:00 urn:sha1:3627e057ddf00759d5985e80a8bb317a1b071a4a X509_CERT_AUX_print(). Commit in -current: CVSROOT: /cvs Module name: src Changes by: schwarze@cvs.openbsd.org 2021/07/10 11:45:16 Modified files: lib/libcrypto/asn1: t_x509a.c Log message: Fix a read buffer overrun in X509_CERT_AUX_print(3), which by implication also affects X509_print(3). The ASN1_STRING_get0_data(3) manual explitely cautions the reader that the data is not necessarily NUL-terminated, and the function X509_alias_set1(3) does not sanitize the data passed into it in any way either, so we must assume the alias->data field is merely a byte array and not necessarily a string in the sense of the C language. I found this bug while writing manual pages for these functions. OK tb@ As an aside, note that the function still produces incomplete and misleading results when the data contains a NUL byte in the middle and that error handling is consistently absent throughout, even though the function provides an "int" return value obviously intended to be 1 for success and 0 for failure, and even though this function is called by another function that also wants to return 1 for success and 0 for failure and even does so in many of its code paths, though not in others. But let's stay focussed. Many things would be nice to have in the wide wild world, but a buffer overflow must not be allowed to remain in our backyard. This is patches/6.9/common/015_x509.patch.sig 2020-12-16T18:46:29+00:00 tb 2020-12-16T18:46:29+00:00 urn:sha1:6beaabfe49252420dfbd80598c2dc71f85ea6a6f pointed out by jsing 2020-12-16T18:35:59+00:00 tb 2020-12-16T18:35:59+00:00 urn:sha1:25fba608b24a7bf868f7cd6c3cb19e964a7ffcd4 When parsing an UTCTime into a struct tm that wasn't cleared by the caller, the years would be added to the already present value, which could give an incorrect result. This is an issue in ASN1_UTCTIME_cmp_time_t(), which is practically unused. Fix this by always zeroing the passed struct tm. Issue reported by Olivier Taïbi, thanks! ok jsing 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-09-03T17:29:05+00:00 tb 2020-09-03T17:29:05+00:00 urn:sha1:992067d5cd15deed65484ab2fc52daa60bb44f7a Instead of using malloc(3) and manually setting part of the structure to zero, part to something else and leaving the rest uninitialized, we can benefit from the fact that there's this thing called calloc(3). Moreover, all variants of free(3) in libcrypto are NULL safe. ok beck inoguchi 2020-09-03T17:19:27+00:00 tb 2020-09-03T17:19:27+00:00 urn:sha1:8324cf873726c94960d258de10aa9deb95117e9c Zap a memset that was redundant since OpenSSL 0.97b was merged by markus in 2003. Nowadays it's otto's recallocarray(3) that does the zeroing. ok beck inoguchi otto PS: ASN1_BIT_STRING_set_bit(3) was committed on Dec 21 1998 by Ralf S. Engelschnall and used this bizarre allocation idiom: if (a->data == NULL) c=(unsigned char *)Malloc(w+1); else c=(unsigned char *)Realloc(a->data,w+1); People complained about Malloc, Realloc and Free being used elsewhere, so on Jun 1 2000, Richarde Levitte swept the OpenSSL tree and it became this. if (a->data == NULL) c=(unsigned char *)OPENSSL_malloc(w+1); else c=(unsigned char *)OPENSSL_realloc(a->data,w+1); Then it was found that existing data should be cleaned, and on Nov 13 2002 Ben Laurie changed the last line to c=(unsigned char *)OPENSSL_realloc_clean(a->data, a->length, w+1); 2020-06-04T21:21:03+00:00 schwarze 2020-06-04T21:21:03+00:00 urn:sha1:be3505dc014b9b7022575b6fe4f9c78c2080281c failure rather than silently constructing a broken X509_ATTRIBUTE object that might cause NULL pointer accesses later on. This matters because X509_ATTRIBUTE_create() is used by documented API functions like PKCS7_add_attribute(3) and the NID comes straight from the user. This fixes a bug found while working on documentation. OK tb@ and "thanks" bluhm@ 2020-04-10T07:05:24+00:00 tb 2020-04-10T07:05:24+00:00 urn:sha1:4689dc5a48a9c21efc191442a6cc826034785951 bytes in case ASN1_INTEGER_get() failed. This happens more often since asn1/a_int.c -r1.34. Matches OpenSSL behavior. Issue in openssl x509 -text output reported by sthen ok jsing sthen 2020-03-24T10:46:38+00:00 inoguchi 2020-03-24T10:46:38+00:00 urn:sha1:eacf3461605a07f186ea238b0a1a1a26cf1aa9ea Check and print out boolean type properly. Based on OpenSSL commit ad72d9fdf7709ddb97a58d7d45d755e6e0504b96. Reduced unneeded parentheses from if condition. Check return value from i2s_ASN1_INTEGER. Based on OpenSSL commit 5e3553c2de9a365479324b8ba8b998f0cce3e527. Added if condition expression and return 0 if NULL is returned. ok tb@ 2020-01-09T11:27:21+00:00 inoguchi 2020-01-09T11:27:21+00:00 urn:sha1:8b9f481b47fe0f92f73f2dfab84982ebc9010790 ok tb@