From: Peter Korsgaard <peter@korsgaard.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] libopenssl: security bump to version 1.0.2o
Date: Sat, 07 Apr 2018 17:41:05 +0200 [thread overview]
Message-ID: <876053f2i6.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <20180329145209.7878-1-peter@korsgaard.com> (Peter Korsgaard's message of "Thu, 29 Mar 2018 16:52:09 +0200")
>>>>> "Peter" == Peter Korsgaard <peter@korsgaard.com> writes:
> Fixes the following security issues:
> Constructed ASN.1 types with a recursive definition could exceed the stack
> (CVE-2018-0739)
> Constructed ASN.1 types with a recursive definition (such as can be found in
> PKCS7) could eventually exceed the stack given malicious input with
> excessive recursion. This could result in a Denial Of Service attack.
> There are no such structures used within SSL/TLS that come from untrusted
> sources so this is considered safe.
> Incorrect CRYPTO_memcmp on HP-UX PA-RISC (CVE-2018-0733)
> Because of an implementation bug the PA-RISC CRYPTO_memcmp function is
> effectively reduced to only comparing the least significant bit of each
> byte. This allows an attacker to forge messages that would be considered as
> authenticated in an amount of tries lower than that guaranteed by the
> security claims of the scheme. The module can only be compiled by the HP-UX
> assembler, so that only HP-UX PA-RISC targets are affected.
> rsaz_1024_mul_avx2 overflow bug on x86_64 (CVE-2017-3738)
> This issue has been reported in a previous OpenSSL security advisory and a
> fix was provided for OpenSSL 1.0.2. Due to the low severity no fix was
> released at that time for OpenSSL 1.1.0. The fix is now available in
> OpenSSL 1.1.0h.
> There is an overflow bug in the AVX2 Montgomery multiplication procedure
> used in exponentiation with 1024-bit moduli. No EC algorithms are affected.
> Analysis suggests that attacks against RSA and DSA as a result of this
> defect would be very difficult to perform and are not believed likely.
> Attacks against DH1024 are considered just feasible, because most of the
> work necessary to deduce information about a private key may be performed
> offline. The amount of resources required for such an attack would be
> significant. However, for an attack on TLS to be meaningful, the server
> would have to share the DH1024 private key among multiple clients, which is
> no longer an option since CVE-2016-0701.
> This only affects processors that support the AVX2 but not ADX extensions
> like Intel Haswell (4th generation).
> For more details, see https://www.openssl.org/news/secadv/20180327.txt
> The copyright year changed in LICENSE, so adjust the hash to match.
> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Committed to 2018.02.x, thanks.
--
Bye, Peter Korsgaard
next prev parent reply other threads:[~2018-04-07 15:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-29 14:52 [Buildroot] [PATCH] libopenssl: security bump to version 1.0.2o Peter Korsgaard
2018-03-30 6:27 ` Peter Korsgaard
2018-04-07 15:41 ` Peter Korsgaard [this message]
2018-04-11 15:46 ` 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=876053f2i6.fsf@dell.be.48ers.dk \
--to=peter@korsgaard.com \
--cc=buildroot@busybox.net \
/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