From owner-freebsd-questions@freebsd.org Tue Aug 24 22:25:37 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0445B667F2D for ; Tue, 24 Aug 2021 22:25:37 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Received: from doctor.nl2k.ab.ca (doctor.nl2k.ab.ca [204.209.81.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GvNwc1Psyz3sbN for ; Tue, 24 Aug 2021 22:25:36 +0000 (UTC) (envelope-from doctor@doctor.nl2k.ab.ca) Received: from doctor by doctor.nl2k.ab.ca with local (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1mIeqD-000DDe-Hl; Tue, 24 Aug 2021 16:24:21 -0600 Date: Tue, 24 Aug 2021 16:24:21 -0600 From: The Doctor To: Dan Langille Cc: freebsd-questions@freebsd.org Subject: Re: [matt@openssl.org: OpenSSL Security Advisory] Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4GvNwc1Psyz3sbN X-Spamd-Bar: +++++ X-Spamd-Result: default: False [5.21 / 15.00]; INTRODUCTION(2.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(0.00)[+a]; GREYLIST(0.00)[pass,meta]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; BAD_REP_POLICIES(0.10)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_VIRUSFREE_BOTNET(2.00)[204.209.81.1:from]; NEURAL_HAM_SHORT(-0.79)[-0.786]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(0.00)[nl2k.ab.ca,quarantine]; NEURAL_SPAM_LONG(1.00)[1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:6171, ipnet:204.209.81.0/24, country:CA]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 22:25:37 -0000 On Tue, Aug 24, 2021 at 05:04:57PM -0400, Dan Langille wrote: > > The Doctor via freebsd-questions wrote on 8/24/21 10:25 AM: > > Is the kernel going to be updated? > > > > Also openssh updates did take place. > > This just in: > > https://lists.freebsd.org/pipermail/freebsd-security-notifications/2021-August/000418.html > I am on that list. > > > > > > ----- Forwarded message from Matt Caswell ----- > > > > Date: Tue, 24 Aug 2021 14:16:11 +0000 > > From: Matt Caswell > > To: openssl-project@openssl.org, openssl-users@openssl.org, > > openssl-announce@openssl.org > > Subject: OpenSSL Security Advisory > > User-Agent: Mutt/1.9.4 (2018-02-28) > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > OpenSSL Security Advisory [24 August 2021] > > ========================================== > > > > SM2 Decryption Buffer Overflow (CVE-2021-3711) > > ============================================== > > > > Severity: High > > > > In order to decrypt SM2 encrypted data an application is expected to call the > > API function EVP_PKEY_decrypt(). Typically an application will call this > > function twice. The first time, on entry, the "out" parameter can be NULL and, > > on exit, the "outlen" parameter is populated with the buffer size required to > > hold the decrypted plaintext. The application can then allocate a sufficiently > > sized buffer and call EVP_PKEY_decrypt() again, but this time passing a non-NULL > > value for the "out" parameter. > > > > A bug in the implementation of the SM2 decryption code means that the > > calculation of the buffer size required to hold the plaintext returned by the > > first call to EVP_PKEY_decrypt() can be smaller than the actual size required by > > the second call. This can lead to a buffer overflow when EVP_PKEY_decrypt() is > > called by the application a second time with a buffer that is too small. > > > > A malicious attacker who is able present SM2 content for decryption to an > > application could cause attacker chosen data to overflow the buffer by up to a > > maximum of 62 bytes altering the contents of other data held after the > > buffer, possibly changing application behaviour or causing the application to > > crash. The location of the buffer is application dependent but is typically > > heap allocated. > > > > OpenSSL versions 1.1.1k and below are affected by this issue. Users of these > > versions should upgrade to OpenSSL 1.1.1l. > > > > OpenSSL 1.0.2 is not impacted by this issue. > > > > OpenSSL 3.0 alpha/beta releases are also affected but this issue will be > > addressed before the final release. > > > > This issue was reported to OpenSSL on 12th August 2021 by John Ouyang. The fix > > was developed by Matt Caswell. > > > > Read buffer overruns processing ASN.1 strings (CVE-2021-3712) > > ============================================================= > > > > Severity: Moderate > > > > ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING > > structure which contains a buffer holding the string data and a field holding > > the buffer length. This contrasts with normal C strings which are repesented as > > a buffer for the string data which is terminated with a NUL (0) byte. > > > > Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's > > own "d2i" functions (and other similar parsing functions) as well as any string > > whose value has been set with the ASN1_STRING_set() function will additionally > > NUL terminate the byte array in the ASN1_STRING structure. > > > > However, it is possible for applications to directly construct valid ASN1_STRING > > structures which do not NUL terminate the byte array by directly setting the > > "data" and "length" fields in the ASN1_STRING array. This can also happen by > > using the ASN1_STRING_set0() function. > > > > Numerous OpenSSL functions that print ASN.1 data have been found to assume that > > the ASN1_STRING byte array will be NUL terminated, even though this is not > > guaranteed for strings that have been directly constructed. Where an application > > requests an ASN.1 structure to be printed, and where that ASN.1 structure > > contains ASN1_STRINGs that have been directly constructed by the application > > without NUL terminating the "data" field, then a read buffer overrun can occur. > > > > The same thing can also occur during name constraints processing of certificates > > (for example if a certificate has been directly constructed by the application > > instead of loading it via the OpenSSL parsing functions, and the certificate > > contains non NUL terminated ASN1_STRING structures). It can also occur in the > > X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. > > > > If a malicious actor can cause an application to directly construct an > > ASN1_STRING and then process it through one of the affected OpenSSL functions > > then this issue could be hit. This might result in a crash (causing a Denial of > > Service attack). It could also result in the disclosure of private memory > > contents (such as private keys, or sensitive plaintext). > > > > OpenSSL versions 1.1.1k and below are affected by this issue. Users of these > > versions should upgrade to OpenSSL 1.1.1l. > > > > OpenSSL versions 1.0.2y and below are affected by this issue. However OpenSSL > > 1.0.2 is out of support and no longer receiving public updates. Premium support > > customers of OpenSSL 1.0.2 should upgrade to 1.0.2za. Other users should upgrade > > to 1.1.1l. > > > > An initial instance of this issue in the X509_aux_print() function was reported > > to OpenSSL on 18th July 2021 by Ingo Schwarze. The bugfix was developed by Ingo > > Schwarze and first publicly released in OpenBSD-current on 10th July 2021 and > > subsequently in OpenSSL on 20th July 2021 (commit d9d838ddc). Subsequent > > analysis by David Benjamin on 17th August 2021 identified more instances of the > > same bug. Additional analysis was performed by Matt Caswell. Fixes for the > > additional instances of this issue were developed by Matt Caswell. > > > > Note > > ==== > > > > OpenSSL 1.0.2 is out of support and no longer receiving public updates. Extended > > support is available for premium support customers: > > https://www.openssl.org/support/contracts.html > > > > OpenSSL 1.1.0 is out of support and no longer receiving updates of any kind. > > The impact of these issues on OpenSSL 1.1.0 has not been analysed. > > > > Users of these versions should upgrade to OpenSSL 1.1.1. > > > > References > > ========== > > > > URL for this Security Advisory: > > https://www.openssl.org/news/secadv/20210824.txt > > > > Note: the online version of the advisory may be updated with additional details > > over time. > > > > For details of OpenSSL severity classifications please see: > > https://www.openssl.org/policies/secpolicy.html > > -----BEGIN PGP SIGNATURE----- > > > > iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmEk/mUACgkQ2cTSbQ5g > > RJFqwgf+JbgzTg6LoHNHCIAHkCwHHq2+bZO4ziGbxNxiSv5+37x3jV2iDxdjUeK6 > > IY87VG0AvjKCD5gN3eMpgOTspO9S2F5fq/q2HE0iIVc8bmR0w3TBvUtFceiBaW2X > > GyEPxtvG5IG5cMT7vEguk1yq3CgKfXqCz88/gya2YvC/9E7idoyi2UQbEYx+VHRU > > j5LDGPqYvqaUhWg7FfSCNZ5grdv9pl0A9Kx+HeoIYAi5LZgrcGScm7JpiU7dRa+L > > 3y1597g6uHOKuGORXkvR9Q61xnNSvOqfV6KLWkMR4PU1a3+Qklpofzub0SZwUIlr > > bgQ+i2Jm0IMrYHOmG8A9UDzNEqnEjA== > > =8QGT > > -----END PGP SIGNATURE----- > > > > ----- End forwarded message ----- > > > > -- > Dan Langille > dan@langille.org : https://langille.org/ > _______________________________________________ > freebsd-questions@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b Canada on 20 Sept 2021 vote ! Beware https://mindspring.com