- Update from version 1.1.1q to 1.1.1s
- Update of rootfile
- Changelog
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.
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.
*) Fixed a strict aliasing problem in bn_nist. Clang-14 optimisation was
causing incorrect results in some cases as a result.
*) Fixed SSL_pending() and SSL_has_pending() with DTLS which were failing to
report correct results in some cases
*) Fixed a regression introduced in 1.1.1o for re-signing certificates with
different key sizes
*) Added the loongarch64 target
*) Fixed a DRBG seed propagation thread safety issue
*) Fixed a memory leak in tls13_generate_secret
*) 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.
*) Added a missing header for memcmp that caused compilation failure on some
platforms
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
- Update from version 1.1.1p to 1.1.1q
- Update of rootfile not required
- Changelog
Changes between 1.1.1p and 1.1.1q [5 Jul 2022]
(CVE-2022-2097) Severity: Moderate
AES OCB mode for 32-bit x86 platforms using the AES-NI assembly optimised
implementation would not encrypt the entirety of the data under some
circumstances. This could reveal sixteen bytes of data that was
preexisting in the memory that wasn't written. In the special case of
"in place" encryption, sixteen bytes of the plaintext would be revealed.
Since OpenSSL does not support OCB based cipher suites for TLS and DTLS,
they are both unaffected.
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
- Update from version 1.1.1n to 1.1.1o
- Update of rootfile not required
- This patch is to go into CU168 as this update is for fixing a moderate severity CVE
- Changelog
1.1.1o [3 May 2022]
(CVE-2022-1292)
Fixed a bug in the c_rehash script which was not properly sanitising shell
metacharacters to prevent command injection. This script is distributed by
some operating systems in a manner where it is automatically executed. On
such operating systems, an attacker could execute arbitrary commands with the
privileges of the script.
Use of the c_rehash script is considered obsolete and should be replaced
by the OpenSSL rehash command line tool.
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
Historically, the MD5 checksums in our LFS files serve as a protection
against broken downloads, or accidentally corrupted source files.
While the sources are nowadays downloaded via HTTPS, it make sense to
beef up integrity protection for them, since transparently intercepting
TLS is believed to be feasible for more powerful actors, and the state
of the public PKI ecosystem is clearly not helping.
Therefore, this patch switches from MD5 to BLAKE2, updating all LFS
files as well as make.sh to deal with this checksum algorithm. BLAKE2 is
notably faster (and more secure) than SHA2, so the performance penalty
introduced by this patch is negligible, if noticeable at all.
In preparation of this patch, the toolchain files currently used have
been supplied with BLAKE2 checksums as well on
https://source.ipfire.org/.
Cc: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-by: Michael Tremer <michael.tremeripfire.org>
OpenSSL Security Advisory [15 March 2022]
============================================
Infinite loop in BN_mod_sqrt() reachable when parsing certificates
(CVE-2022-0778)
==================================================================================
Severity: High
The BN_mod_sqrt() function, which computes a modular square root,
contains
a bug that can cause it to loop forever for non-prime moduli.
Internally this function is used when parsing certificates that contain
elliptic curve public keys in compressed form or explicit elliptic curve
parameters with a base point encoded in compressed form.
It is possible to trigger the infinite loop by crafting a certificate
that
has invalid explicit curve parameters.
Since certificate parsing happens prior to verification of the
certificate
signature, any process that parses an externally supplied certificate
may thus
be subject to a denial of service attack. The infinite loop can also be
reached when parsing crafted private keys as they can contain explicit
elliptic curve parameters.
Thus vulnerable situations include:
- TLS clients consuming server certificates
- TLS servers consuming client certificates
- Hosting providers taking certificates or private keys from customers
- Certificate authorities parsing certification requests from
subscribers
- Anything else which parses ASN.1 elliptic curve parameters
Also any other applications that use the BN_mod_sqrt() where the
attacker
can control the parameter values are vulnerable to this DoS issue.
In the OpenSSL 1.0.2 version the public key is not parsed during initial
parsing of the certificate which makes it slightly harder to trigger
the infinite loop. However any operation which requires the public key
from the certificate will trigger the infinite loop. In particular the
attacker can use a self-signed certificate to trigger the loop during
verification of the certificate signature.
This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was
addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022.
OpenSSL 1.0.2 users should upgrade to 1.0.2zd (premium support customers
only)
OpenSSL 1.1.1 users should upgrade to 1.1.1n
OpenSSL 3.0 users should upgrade to 3.0.2
This issue was reported to OpenSSL on the 24th February 2022 by Tavis
Ormandy
from Google. The fix was developed by David Benjamin from Google and
Tomáš Mráz
from OpenSSL.
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.
It is affected by the issue.
Users of these versions should upgrade to OpenSSL 3.0 or 1.1.1.
References
==========
URL for this Security Advisory:
https://www.openssl.org/news/secadv/20220315.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
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Full changelog as per https://www.openssl.org/news/cl111.txt :
Changes between 1.1.1l and 1.1.1m [14 Dec 2021]
*) Avoid loading of a dynamic engine twice.
[Bernd Edlinger]
*) Fixed building on Debian with kfreebsd kernels
[Mattias Ellert]
*) Prioritise DANE TLSA issuer certs over peer certs
[Viktor Dukhovni]
*) Fixed random API for MacOS prior to 10.12
These MacOS versions don't support the CommonCrypto APIs
[Lenny Primak]
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
This patch removes support for i586 according to the decision being
taken over a year ago.
It removes the architecture from the build system and removes all
required hacks and other quirks that have been necessary before.
There is no need to ship any changed files to the remaining
architectures as the removed code branches have not been used.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
From https://www.openssl.org/news/secadv/20210325.txt:
OpenSSL Security Advisory [25 March 2021]
=========================================
CA certificate check bypass with X509_V_FLAG_X509_STRICT (CVE-2021-3450)
========================================================================
Severity: High
The X509_V_FLAG_X509_STRICT flag enables additional security checks of the
certificates present in a certificate chain. It is not set by default.
Starting from OpenSSL version 1.1.1h a check to disallow certificates in
the chain that have explicitly encoded elliptic curve parameters was added
as an additional strict check.
An error in the implementation of this check meant that the result of a
previous check to confirm that certificates in the chain are valid CA
certificates was overwritten. This effectively bypasses the check
that non-CA certificates must not be able to issue other certificates.
If a "purpose" has been configured then there is a subsequent opportunity
for checks that the certificate is a valid CA. All of the named "purpose"
values implemented in libcrypto perform this check. Therefore, where
a purpose is set the certificate chain will still be rejected even when the
strict flag has been used. A purpose is set by default in libssl client and
server certificate verification routines, but it can be overridden or
removed by an application.
In order to be affected, an application must explicitly set the
X509_V_FLAG_X509_STRICT verification flag and either not set a purpose
for the certificate verification or, in the case of TLS client or server
applications, override the default purpose.
OpenSSL versions 1.1.1h and newer are affected by this issue. Users of these
versions should upgrade to OpenSSL 1.1.1k.
OpenSSL 1.0.2 is not impacted by this issue.
This issue was reported to OpenSSL on 18th March 2021 by Benjamin Kaduk
from Akamai and was discovered by Xiang Ding and others at Akamai. The fix was
developed by Tomáš Mráz.
NULL pointer deref in signature_algorithms processing (CVE-2021-3449)
=====================================================================
Severity: High
An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation
ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits
the signature_algorithms extension (where it was present in the initial
ClientHello), but includes a signature_algorithms_cert extension then a NULL
pointer dereference will result, leading to a crash and a denial of service
attack.
A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which
is the default configuration). OpenSSL TLS clients are not impacted by this
issue.
All OpenSSL 1.1.1 versions are affected by this issue. Users of these versions
should upgrade to OpenSSL 1.1.1k.
OpenSSL 1.0.2 is not impacted by this issue.
This issue was reported to OpenSSL on 17th March 2021 by Nokia. The fix was
developed by Peter Kästle and Samuel Sapalski from Nokia.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Null pointer deref in X509_issuer_and_serial_hash() (CVE-2021-23841)
====================================================================
Severity: Moderate
The OpenSSL public API function X509_issuer_and_serial_hash() attempts to
create a unique hash value based on the issuer and serial number data contained
within an X509 certificate. However it fails to correctly handle any errors
that may occur while parsing the issuer field (which might occur if the issuer
field is maliciously constructed). This may subsequently result in a NULL
pointer deref and a crash leading to a potential denial of service attack.
The function X509_issuer_and_serial_hash() is never directly called by OpenSSL
itself so applications are only vulnerable if they use this function directly
and they use it on certificates that may have been obtained from untrusted
sources.
OpenSSL versions 1.1.1i and below are affected by this issue. Users of these
versions should upgrade to OpenSSL 1.1.1j.
OpenSSL versions 1.0.2x 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.2y. Other users should upgrade
to 1.1.1j.
This issue was reported to OpenSSL on 15th December 2020 by Tavis Ormandy from
Google. The fix was developed by Matt Caswell.
Incorrect SSLv2 rollback protection (CVE-2021-23839)
====================================================
Severity: Low
OpenSSL 1.0.2 supports SSLv2. If a client attempts to negotiate SSLv2 with a
server that is configured to support both SSLv2 and more recent SSL and TLS
versions then a check is made for a version rollback attack when unpadding an
RSA signature. Clients that support SSL or TLS versions greater than SSLv2 are
supposed to use a special form of padding. A server that supports greater than
SSLv2 is supposed to reject connection attempts from a client where this special
form of padding is present, because this indicates that a version rollback has
occurred (i.e. both client and server support greater than SSLv2, and yet this
is the version that is being requested).
The implementation of this padding check inverted the logic so that the
connection attempt is accepted if the padding is present, and rejected if it
is absent. This means that such as server will accept a connection if a version
rollback attack has occurred. Further the server will erroneously reject a
connection if a normal SSLv2 connection attempt is made.
Only OpenSSL 1.0.2 servers from version 1.0.2s to 1.0.2x are affected by this
issue. In order to be vulnerable a 1.0.2 server must:
1) have configured SSLv2 support at compile time (this is off by default),
2) have configured SSLv2 support at runtime (this is off by default),
3) have configured SSLv2 ciphersuites (these are not in the default ciphersuite
list)
OpenSSL 1.1.1 does not have SSLv2 support and therefore is not vulnerable to
this issue. The underlying error is in the implementation of the
RSA_padding_check_SSLv23() function. This also affects the RSA_SSLV23_PADDING
padding mode used by various other functions. Although 1.1.1 does not support
SSLv2 the RSA_padding_check_SSLv23() function still exists, as does the
RSA_SSLV23_PADDING padding mode. Applications that directly call that function
or use that padding mode will encounter this issue. However since there is no
support for the SSLv2 protocol in 1.1.1 this is considered a bug and not a
security issue in that version.
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.2y. Other users should
upgrade to 1.1.1j.
This issue was reported to OpenSSL on 21st January 2021 by D. Katz and Joel
Luellwitz from Trustwave. The fix was developed by Matt Caswell.
Integer overflow in CipherUpdate (CVE-2021-23840)
=================================================
Severity: Low
Calls to EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate may overflow
the output length argument in some cases where the input length is close to the
maximum permissable length for an integer on the platform. In such cases the
return value from the function call will be 1 (indicating success), but the
output length value will be negative. This could cause applications to behave
incorrectly or crash.
OpenSSL versions 1.1.1i and below are affected by this issue. Users of these
versions should upgrade to OpenSSL 1.1.1j.
OpenSSL versions 1.0.2x 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.2y. Other users should upgrade
to 1.1.1j.
This issue was reported to OpenSSL on 13th December 2020 by Paul Kehrer. The fix
was developed by Matt Caswell.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
fix: EDIPARTYNAME NULL pointer de-reference (CVE-2020-1971)
Severity: High
The X.509 GeneralName type is a generic type for representing different types
of names. One of those name types is known as EDIPartyName. OpenSSL provides a
function GENERAL_NAME_cmp which compares different instances of a GENERAL_NAME
to see if they are equal or not. This function behaves incorrectly when both
GENERAL_NAMEs contain an EDIPARTYNAME. A NULL pointer dereference and a crash
may occur leading to a possible denial of service attack.
OpenSSL itself uses the GENERAL_NAME_cmp function for two purposes:
1) Comparing CRL distribution point names between an available CRL and a CRL
distribution point embedded in an X509 certificate
2) When verifying that a timestamp response token signer matches the timestamp
authority name (exposed via the API functions TS_RESP_verify_response and
TS_RESP_verify_token)
If an attacker can control both items being compared then that attacker could
trigger a crash. For example if the attacker can trick a client or server into
checking a malicious certificate against a malicious CRL then this may occur.
Note that some applications automatically download CRLs based on a URL embedded
in a certificate. This checking happens prior to the signatures on the
certificate and CRL being verified. OpenSSL's s_server, s_client and verify
tools have support for the "-crl_download" option which implements automatic
CRL downloading and this attack has been demonstrated to work against those
tools.
Note that an unrelated bug means that affected versions of OpenSSL cannot parse
or construct correct encodings of EDIPARTYNAME. However it is possible to
construct a malformed EDIPARTYNAME that OpenSSL's parser will accept and hence
trigger this attack.
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
CVE-2020-1967 (OpenSSL advisory) [High severity] 21 April 2020:
Server or client applications that call the SSL_check_chain()
function during or after a TLS 1.3 handshake may crash due
to a NULL pointer dereference as a result of incorrect handling
of the "signature_algorithms_cert" TLS extension.
The crash occurs if an invalid or unrecognised signature algorithm
is received from the peer. This could be exploited by a malicious
peer in a Denial of Service attack.
https://www.openssl.org/news/secadv/20200421.txt
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Fixed an overflow bug in the x64_64 Montgomery squaring procedure used
in exponentiation with 512-bit moduli (CVE-2019-1551).
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Disabled MD2 and Aria cipher.
TLSv1.3 is now available with:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3
TLS_AES_256_GCM_SHA384 TLSv1.3
TLS_AES_128_GCM_SHA256 TLSv1.3
Signed-off-by: Erik Kapfer <ummeegge@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
*) Timing vulnerability in DSA signature generation
The OpenSSL DSA signature algorithm has been shown to be vulnerable to a
timing side channel attack. An attacker could use variations in the signing
algorithm to recover the private key.
This issue was reported to OpenSSL on 16th October 2018 by Samuel Weiser.
(CVE-2018-0734)
[Paul Dale]
*) Timing vulnerability in ECDSA signature generation
The OpenSSL ECDSA signature algorithm has been shown to be vulnerable to a
timing side channel attack. An attacker could use variations in the signing
algorithm to recover the private key.
This issue was reported to OpenSSL on 25th October 2018 by Samuel Weiser.
(CVE-2018-0735)
[Paul Dale]
*) Add coordinate blinding for EC_POINT and implement projective
coordinate blinding for generic prime curves as a countermeasure to
chosen point SCA attacks.
[Sohaib ul Hassan, Nicola Tuveri, Billy Bob Brumley]
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Changes between 1.1.0h and 1.1.0i [14 Aug 2018]
*) Client DoS due to large DH parameter
During key agreement in a TLS handshake using a DH(E) based ciphersuite a
malicious server can send a very large prime value to the client. This will
cause the client to spend an unreasonably long period of time generating a
key for this prime resulting in a hang until the client has finished. This
could be exploited in a Denial Of Service attack.
This issue was reported to OpenSSL on 5th June 2018 by Guido Vranken
(CVE-2018-0732)
[Guido Vranken]
*) Cache timing vulnerability in RSA Key Generation
The OpenSSL RSA Key generation algorithm has been shown to be vulnerable to
a cache timing side channel attack. An attacker with sufficient access to
mount cache timing attacks during the RSA key generation process could
recover the private key.
This issue was reported to OpenSSL on 4th April 2018 by Alejandro Cabrera
Aldaya, Billy Brumley, Cesar Pereida Garcia and Luis Manuel Alvarez Tapia.
(CVE-2018-0737)
[Billy Brumley]
*) Make EVP_PKEY_asn1_new() a bit stricter about its input. A NULL pem_str
parameter is no longer accepted, as it leads to a corrupt table. NULL
pem_str is reserved for alias entries only.
[Richard Levitte]
*) Revert blinding in ECDSA sign and instead make problematic addition
length-invariant. Switch even to fixed-length Montgomery multiplication.
[Andy Polyakov]
*) Change generating and checking of primes so that the error rate of not
being prime depends on the intended use based on the size of the input.
For larger primes this will result in more rounds of Miller-Rabin.
The maximal error rate for primes with more than 1080 bits is lowered
to 2^-128.
[Kurt Roeckx, Annie Yousar]
*) Increase the number of Miller-Rabin rounds for DSA key generating to 64.
[Kurt Roeckx]
*) Add blinding to ECDSA and DSA signatures to protect against side channel
attacks discovered by Keegan Ryan (NCC Group).
[Matt Caswell]
*) When unlocking a pass phrase protected PEM file or PKCS#8 container, we
now allow empty (zero character) pass phrases.
[Richard Levitte]
*) Certificate time validation (X509_cmp_time) enforces stricter
compliance with RFC 5280. Fractional seconds and timezone offsets
are no longer allowed.
[Emilia Käsper]
*) Fixed a text canonicalisation bug in CMS
Where a CMS detached signature is used with text content the text goes
through a canonicalisation process first prior to signing or verifying a
signature. This process strips trailing space at the end of lines, converts
line terminators to CRLF and removes additional trailing line terminators
at the end of a file. A bug in the canonicalisation process meant that
some characters, such as form-feed, were incorrectly treated as whitespace
and removed. This is contrary to the specification (RFC5485). This fix
could mean that detached text data signed with an earlier version of
OpenSSL 1.1.0 may fail to verify using the fixed version, or text data
signed with a fixed OpenSSL may fail to verify with an earlier version of
OpenSSL 1.1.0. A workaround is to only verify the canonicalised text data
and use the "-binary" flag (for the "cms" command line application) or set
the SMIME_BINARY/PKCS7_BINARY/CMS_BINARY flags (if using CMS_verify()).
[Matt Caswell]
Changes between 1.0.2o and 1.0.2p [14 Aug 2018]
*) Client DoS due to large DH parameter
During key agreement in a TLS handshake using a DH(E) based ciphersuite a
malicious server can send a very large prime value to the client. This will
cause the client to spend an unreasonably long period of time generating a
key for this prime resulting in a hang until the client has finished. This
could be exploited in a Denial Of Service attack.
This issue was reported to OpenSSL on 5th June 2018 by Guido Vranken
(CVE-2018-0732)
[Guido Vranken]
*) Cache timing vulnerability in RSA Key Generation
The OpenSSL RSA Key generation algorithm has been shown to be vulnerable to
a cache timing side channel attack. An attacker with sufficient access to
mount cache timing attacks during the RSA key generation process could
recover the private key.
This issue was reported to OpenSSL on 4th April 2018 by Alejandro Cabrera
Aldaya, Billy Brumley, Cesar Pereida Garcia and Luis Manuel Alvarez Tapia.
(CVE-2018-0737)
[Billy Brumley]
*) Make EVP_PKEY_asn1_new() a bit stricter about its input. A NULL pem_str
parameter is no longer accepted, as it leads to a corrupt table. NULL
pem_str is reserved for alias entries only.
[Richard Levitte]
*) Revert blinding in ECDSA sign and instead make problematic addition
length-invariant. Switch even to fixed-length Montgomery multiplication.
[Andy Polyakov]
*) Change generating and checking of primes so that the error rate of not
being prime depends on the intended use based on the size of the input.
For larger primes this will result in more rounds of Miller-Rabin.
The maximal error rate for primes with more than 1080 bits is lowered
to 2^-128.
[Kurt Roeckx, Annie Yousar]
*) Increase the number of Miller-Rabin rounds for DSA key generating to 64.
[Kurt Roeckx]
*) Add blinding to ECDSA and DSA signatures to protect against side channel
attacks discovered by Keegan Ryan (NCC Group).
[Matt Caswell]
*) When unlocking a pass phrase protected PEM file or PKCS#8 container, we
now allow empty (zero character) pass phrases.
[Richard Levitte]
*) Certificate time validation (X509_cmp_time) enforces stricter
compliance with RFC 5280. Fractional seconds and timezone offsets
are no longer allowed.
[Emilia Käsper]
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
CVE-2018-0739 (OpenSSL advisory) [Moderate severity] 27 March 2018:
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.
Reported by OSS-fuzz.
This patch also entirely removes support for SSLv3. The patch to
disable it didn't apply and since nobody has been using this before,
we will not compile it into OpenSSL any more.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
OpenSSL Security Advisory [07 Dec 2017]
========================================
Read/write after SSL object in error state (CVE-2017-3737)
==========================================================
Severity: Moderate
OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state"
mechanism. The intent was that if a fatal error occurred during a handshake then
OpenSSL would move into the error state and would immediately fail if you
attempted to continue the handshake. This works as designed for the explicit
handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()),
however due to a bug it does not work correctly if SSL_read() or SSL_write() is
called directly. In that scenario, if the handshake fails then a fatal error
will be returned in the initial function call. If SSL_read()/SSL_write() is
subsequently called by the application for the same SSL object then it will
succeed and the data is passed without being decrypted/encrypted directly from
the SSL/TLS record layer.
In order to exploit this issue an application bug would have to be present that
resulted in a call to SSL_read()/SSL_write() being issued after having already
received a fatal error.
This issue does not affect OpenSSL 1.1.0.
OpenSSL 1.0.2 users should upgrade to 1.0.2n
This issue was reported to OpenSSL on 10th November 2017 by David Benjamin
(Google). The fix was proposed by David Benjamin and implemented by Matt Caswell
of the OpenSSL development team.
rsaz_1024_mul_avx2 overflow bug on x86_64 (CVE-2017-3738)
=========================================================
Severity: Low
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).
Note: The impact from this issue is similar to CVE-2017-3736, CVE-2017-3732
and CVE-2015-3193.
Due to the low severity of this issue we are not issuing a new release of
OpenSSL 1.1.0 at this time. The fix will be included in OpenSSL 1.1.0h when it
becomes available. The fix is also available in commit e502cc86d in the OpenSSL
git repository.
OpenSSL 1.0.2 users should upgrade to 1.0.2n
This issue was reported to OpenSSL on 22nd November 2017 by David Benjamin
(Google). The issue was originally found via the OSS-Fuzz project. The fix was
developed by Andy Polyakov of the OpenSSL development team.
Note
====
Support for version 1.0.1 ended on 31st December 2016. Support for versions
0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer
receiving security updates.
References
==========
URL for this Security Advisory:
https://www.openssl.org/news/secadv/20171207.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
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
* bn_sqrx8x_internal carry bug on x86_64 (CVE-2017-3736)
* Malformed X.509 IPAddressFamily could cause OOB read (CVE-2017-3735)
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The build environment is using a number of variables which
occasionally conflicted with some other build systems.
This patch cleans that up by renaming some variables and
later unexporting them in the lfs files.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
https://www.openssl.org/news/secadv/20170126.txt
Truncated packet could crash via OOB read (CVE-2017-3731)
=========================================================
Severity: Moderate
If an SSL/TLS server or client is running on a 32-bit host, and a specific
cipher is being used, then a truncated packet can cause that server or client
to perform an out-of-bounds read, usually resulting in a crash.
For OpenSSL 1.1.0, the crash can be triggered when using CHACHA20/POLY1305;
users should upgrade to 1.1.0d
For Openssl 1.0.2, the crash can be triggered when using RC4-MD5; users who have
not disabled that algorithm should update to 1.0.2k
This issue was reported to OpenSSL on 13th November 2016 by Robert Święcki of
Google. The fix was developed by Andy Polyakov of the OpenSSL development team.
Bad (EC)DHE parameters cause a client crash (CVE-2017-3730)
===========================================================
Severity: Moderate
If a malicious server supplies bad parameters for a DHE or ECDHE key exchange
then this can result in the client attempting to dereference a NULL pointer
leading to a client crash. This could be exploited in a Denial of Service
attack.
OpenSSL 1.1.0 users should upgrade to 1.1.0d
This issue does not affect OpenSSL version 1.0.2.
Note that this issue was fixed prior to it being recognised as a security
concern. This means the git commit with the fix does not contain the CVE
identifier. The relevant fix commit can be identified by commit hash efbe126e3.
This issue was reported to OpenSSL on 14th January 2017 by Guido Vranken. The
fix was developed by Matt Caswell of the OpenSSL development team.
BN_mod_exp may produce incorrect results on x86_64 (CVE-2017-3732)
==================================================================
Severity: Moderate
There is a carry propagating bug in the x86_64 Montgomery squaring procedure. 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 DH are considered just feasible (although very
difficult) 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 very significant and likely only
accessible to a limited number of attackers. An attacker would
additionally need online access to an unpatched system using the target
private key in a scenario with persistent DH parameters and a private
key that is shared between multiple clients. For example this can occur by
default in OpenSSL DHE based SSL/TLS ciphersuites. Note: This issue is very
similar to CVE-2015-3193 but must be treated as a separate problem.
OpenSSL 1.1.0 users should upgrade to 1.1.0d
OpenSSL 1.0.2 users should upgrade to 1.0.2k
This issue was reported to OpenSSL on 15th January 2017 by the OSS-Fuzz project.
The fix was developed by Andy Polyakov of the OpenSSL development team.
Montgomery multiplication may produce incorrect results (CVE-2016-7055)
=======================================================================
Severity: Low
This issue was previously fixed in 1.1.0c and covered in security advisory
https://www.openssl.org/news/secadv/20161110.txt
OpenSSL 1.0.2 users should upgrade to 1.0.2k
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Missing CRL sanity check (CVE-2016-7052)
========================================
Severity: Moderate
This issue only affects OpenSSL 1.0.2i, released on 22nd September 2016.
A bug fix which included a CRL sanity check was added to OpenSSL 1.1.0
but was omitted from OpenSSL 1.0.2i. As a result any attempt to use
CRLs in OpenSSL 1.0.2i will crash with a null pointer exception.
OpenSSL 1.0.2i users should upgrade to 1.0.2j
The issue was reported to OpenSSL on 22nd September 2016 by Bruce Stephens and
Thomas Jakobi. The fix was developed by Matt Caswell of the OpenSSL development
team.
https://www.openssl.org/news/secadv/20160926.txt
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
OpenSSL Security Advisory [3 Dec 2015]
=======================================
NOTE: WE ANTICIPATE THAT 1.0.0t AND 0.9.8zh WILL BE THE LAST RELEASES FOR THE
0.9.8 AND 1.0.0 VERSIONS AND THAT NO MORE SECURITY FIXES WILL BE PROVIDED (AS
PER PREVIOUS ANNOUNCEMENTS). USERS ARE ADVISED TO UPGRADE TO LATER VERSIONS.
BN_mod_exp may produce incorrect results on x86_64 (CVE-2015-3193)
==================================================================
Severity: Moderate
There is a carry propagating bug in the x86_64 Montgomery squaring procedure. 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 DH are considered just feasible (although very
difficult) 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 very significant and likely only
accessible to a limited number of attackers. An attacker would
additionally need online access to an unpatched system using the target
private key in a scenario with persistent DH parameters and a private
key that is shared between multiple clients. For example this can occur by
default in OpenSSL DHE based SSL/TLS ciphersuites.
This issue affects OpenSSL version 1.0.2.
OpenSSL 1.0.2 users should upgrade to 1.0.2e
This issue was reported to OpenSSL on August 13 2015 by Hanno
Böck. The fix was developed by Andy Polyakov of the OpenSSL
development team.
Certificate verify crash with missing PSS parameter (CVE-2015-3194)
===================================================================
Severity: Moderate
The signature verification routines will crash with a NULL pointer dereference
if presented with an ASN.1 signature using the RSA PSS algorithm and absent
mask generation function parameter. Since these routines are used to verify
certificate signature algorithms this can be used to crash any certificate
verification operation and exploited in a DoS attack. Any application which
performs certificate verification is vulnerable including OpenSSL clients and
servers which enable client authentication.
This issue affects OpenSSL versions 1.0.2 and 1.0.1.
OpenSSL 1.0.2 users should upgrade to 1.0.2e
OpenSSL 1.0.1 users should upgrade to 1.0.1q
This issue was reported to OpenSSL on August 27 2015 by Loïc Jonas Etienne
(Qnective AG). The fix was developed by Dr. Stephen Henson of the OpenSSL
development team.
X509_ATTRIBUTE memory leak (CVE-2015-3195)
==========================================
Severity: Moderate
When presented with a malformed X509_ATTRIBUTE structure OpenSSL will leak
memory. This structure is used by the PKCS#7 and CMS routines so any
application which reads PKCS#7 or CMS data from untrusted sources is affected.
SSL/TLS is not affected.
This issue affects OpenSSL versions 1.0.2 and 1.0.1, 1.0.0 and 0.9.8.
OpenSSL 1.0.2 users should upgrade to 1.0.2e
OpenSSL 1.0.1 users should upgrade to 1.0.1q
OpenSSL 1.0.0 users should upgrade to 1.0.0t
OpenSSL 0.9.8 users should upgrade to 0.9.8zh
This issue was reported to OpenSSL on November 9 2015 by Adam Langley
(Google/BoringSSL) using libFuzzer. The fix was developed by Dr. Stephen
Henson of the OpenSSL development team.
Race condition handling PSK identify hint (CVE-2015-3196)
=========================================================
Severity: Low
If PSK identity hints are received by a multi-threaded client then
the values are wrongly updated in the parent SSL_CTX structure. This can
result in a race condition potentially leading to a double free of the
identify hint data.
This issue was fixed in OpenSSL 1.0.2d and 1.0.1p but has not been previously
listed in an OpenSSL security advisory. This issue also affects OpenSSL 1.0.0
and has not been previously fixed in an OpenSSL 1.0.0 release.
OpenSSL 1.0.2 users should upgrade to 1.0.2d
OpenSSL 1.0.1 users should upgrade to 1.0.1p
OpenSSL 1.0.0 users should upgrade to 1.0.0t
The fix for this issue can be identified in the OpenSSL git repository by commit
ids 3c66a669dfc7 (1.0.2), d6be3124f228 (1.0.1) and 1392c238657e (1.0.0).
The fix was developed by Dr. Stephen Henson of the OpenSSL development team.
Note
====
As per our previous announcements and our Release Strategy
(https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions
1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these
versions will be provided after that date. In the absence of significant
security issues being identified prior to that date, the 1.0.0t and 0.9.8zh
releases will be the last for those versions. Users of these versions are
advised to upgrade.
References
==========
URL for this Security Advisory:
https://www.openssl.org/news/secadv/20151203.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/about/secpolicy.html
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
