From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Peter Seiderer <ps.report@gmx.net>
Cc: Matt Weber <matthew.weber@collins.com>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v1] package/libopenssl: security bump to version 1.1.1t
Date: Wed, 8 Feb 2023 17:43:05 +0100 [thread overview]
Message-ID: <20230208174305.1af25bae@windsurf> (raw)
In-Reply-To: <20230208162534.28581-1-ps.report@gmx.net>
On Wed, 8 Feb 2023 17:25:34 +0100
Peter Seiderer <ps.report@gmx.net> wrote:
> Changelog (for details see [1] and [2]):
>
> Changes between 1.1.1s and 1.1.1t [7 Feb 2023]
>
> *) Fixed X.400 address type confusion in X.509 GeneralName.
>
> There is a type confusion vulnerability relating to X.400 address processing
> inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING
> but subsequently interpreted by GENERAL_NAME_cmp as an ASN1_TYPE. This
> vulnerability may allow an attacker who can provide a certificate chain and
> CRL (neither of which need have a valid signature) to pass arbitrary
> pointers to a memcmp call, creating a possible read primitive, subject to
> some constraints. Refer to the advisory for more information. Thanks to
> David Benjamin for discovering this issue. (CVE-2023-0286)
>
> This issue has been fixed by changing the public header file definition of
> GENERAL_NAME so that x400Address reflects the implementation. It was not
> possible for any existing application to successfully use the existing
> definition; however, if any application references the x400Address field
> (e.g. in dead code), note that the type of this field has changed. There is
> no ABI change.
> [Hugo Landau]
>
> *) Fixed Use-after-free following BIO_new_NDEF.
>
> The public API function BIO_new_NDEF is a helper function used for
> streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL
> to support the SMIME, CMS and PKCS7 streaming capabilities, but may also
> be called directly by end user applications.
>
> The function receives a BIO from the caller, prepends a new BIO_f_asn1
> filter BIO onto the front of it to form a BIO chain, and then returns
> the new head of the BIO chain to the caller. Under certain conditions,
> for example if a CMS recipient public key is invalid, the new filter BIO
> is freed and the function returns a NULL result indicating a failure.
> However, in this case, the BIO chain is not properly cleaned up and the
> BIO passed by the caller still retains internal pointers to the previously
> freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO
> then a use-after-free will occur. This will most likely result in a crash.
> (CVE-2023-0215)
> [Viktor Dukhovni, Matt Caswell]
>
> *) Fixed Double free after calling PEM_read_bio_ex.
>
> The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and
> decodes the "name" (e.g. "CERTIFICATE"), any header data and the payload
> data. If the function succeeds then the "name_out", "header" and "data"
> arguments are populated with pointers to buffers containing the relevant
> decoded data. The caller is responsible for freeing those buffers. It is
> possible to construct a PEM file that results in 0 bytes of payload data.
> In this case PEM_read_bio_ex() will return a failure code but will populate
> the header argument with a pointer to a buffer that has already been freed.
> If the caller also frees this buffer then a double free will occur. This
> will most likely lead to a crash.
>
> The functions PEM_read_bio() and PEM_read() are simple wrappers around
> PEM_read_bio_ex() and therefore these functions are also directly affected.
>
> These functions are also called indirectly by a number of other OpenSSL
> functions including PEM_X509_INFO_read_bio_ex() and
> SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL
> internal uses of these functions are not vulnerable because the caller does
> not free the header argument if PEM_read_bio_ex() returns a failure code.
> (CVE-2022-4450)
> [Kurt Roeckx, Matt Caswell]
>
> *) Fixed Timing Oracle in RSA Decryption.
>
> A timing based side channel exists in the OpenSSL RSA Decryption
> implementation which could be sufficient to recover a plaintext across
> a network in a Bleichenbacher style attack. To achieve a successful
> decryption an attacker would have to be able to send a very large number
> of trial messages for decryption. The vulnerability affects all RSA padding
> modes: PKCS#1 v1.5, RSA-OEAP and RSASVE.
> (CVE-2022-4304)
> [Dmitry Belyavsky, Hubert Kario]
>
> Changes between 1.1.1r and 1.1.1s [1 Nov 2022]
>
> *) Fixed a regression introduced in 1.1.1r version not refreshing the
> certificate data to be signed before signing the certificate.
> [Gibeom Gwon]
>
> Changes between 1.1.1q and 1.1.1r [11 Oct 2022]
>
> *) Fixed the linux-mips64 Configure target which was missing the
> SIXTY_FOUR_BIT bn_ops flag. This was causing heap corruption on that
> platform.
> [Adam Joseph]
>
> *) Fixed a strict aliasing problem in bn_nist. Clang-14 optimisation was
> causing incorrect results in some cases as a result.
> [Paul Dale]
>
> *) Fixed SSL_pending() and SSL_has_pending() with DTLS which were failing to
> report correct results in some cases
> [Matt Caswell]
>
> *) Fixed a regression introduced in 1.1.1o for re-signing certificates with
> different key sizes
> [Todd Short]
>
> *) Added the loongarch64 target
> [Shi Pujin]
>
> *) Fixed a DRBG seed propagation thread safety issue
> [Bernd Edlinger]
>
> *) Fixed a memory leak in tls13_generate_secret
> [Bernd Edlinger]
>
> *) Fixed reported performance degradation on aarch64. Restored the
> implementation prior to commit 2621751 ("aes/asm/aesv8-armx.pl: avoid
> 32-bit lane assignment in CTR mode") for 64bit targets only, since it is
> reportedly 2-17% slower and the silicon errata only affects 32bit targets.
> The new algorithm is still used for 32 bit targets.
> [Bernd Edlinger]
>
> *) Added a missing header for memcmp that caused compilation failure on some
> platforms
> [Gregor Jasny]
>
> [1] https://www.openssl.org/news/cl111.txt
> [2] https://www.openssl.org/news/vulnerabilities.html
>
> Signed-off-by: Peter Seiderer <ps.report@gmx.net>
> ---
> package/libopenssl/libopenssl.hash | 4 ++--
> package/libopenssl/libopenssl.mk | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
Applied to master, thanks.
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2023-02-08 16:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-08 16:25 [Buildroot] [PATCH v1] package/libopenssl: security bump to version 1.1.1t Peter Seiderer
2023-02-08 16:43 ` Thomas Petazzoni via buildroot [this message]
2023-02-20 5:20 ` Scott Fan
2023-02-28 16:15 ` Peter Korsgaard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230208174305.1af25bae@windsurf \
--to=buildroot@buildroot.org \
--cc=matthew.weber@collins.com \
--cc=ps.report@gmx.net \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox