* A file in PKCS12 format can contain certificates and keys and may come from
an untrusted source. The PKCS12 specification allows certain fields to be
NULL, but OpenSSL did not correctly check for this case. A fix has been
applied to prevent a NULL pointer dereference that results in OpenSSL
crashing. If an application processes PKCS12 files from an untrusted source
using the OpenSSL APIs then that application will be vulnerable to this
issue prior to this fix.
OpenSSL APIs that were vulnerable to this are: PKCS12_parse(),
PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()
and PKCS12_newpass().
We have also fixed a similar issue in SMIME_write_PKCS7(). However since this
function is related to writing data we do not consider it security
significant.
([CVE-2024-0727])
*Matt Caswell*
* When function EVP_PKEY_public_check() is called on RSA public keys,
a computation is done to confirm that the RSA modulus, n, is composite.
For valid RSA keys, n is a product of two or more large primes and this
computation completes quickly. However, if n is an overly large prime,
then this computation would take a long time.
An application that calls EVP_PKEY_public_check() and supplies an RSA key
obtained from an untrusted source could be vulnerable to a Denial of Service
attack.
The function EVP_PKEY_public_check() is not called from other OpenSSL
functions however it is called from the OpenSSL pkey command line
application. For that reason that application is also vulnerable if used
with the "-pubin" and "-check" options on untrusted data.
To resolve this issue RSA keys larger than OPENSSL_RSA_MAX_MODULUS_BITS will
now fail the check immediately with an RSA_R_MODULUS_TOO_LARGE error reason.
([CVE-2023-6237])
*Tomáš Mráz*
* Restore the encoding of SM2 PrivateKeyInfo and SubjectPublicKeyInfo to
have the contained AlgorithmIdentifier.algorithm set to id-ecPublicKey
rather than SM2.
*Richard Levitte*
* The POLY1305 MAC (message authentication code) implementation in OpenSSL
for PowerPC CPUs saves the contents of vector registers in different
order than they are restored. Thus the contents of some of these vector
registers is corrupted when returning to the caller. The vulnerable code is
used only on newer PowerPC processors supporting the PowerISA 2.07
instructions.
The consequences of this kind of internal application state corruption can
be various - from no consequences, if the calling application does not
depend on the contents of non-volatile XMM registers at all, to the worst
consequences, where the attacker could get complete control of the
application process. However unless the compiler uses the vector registers
for storing pointers, the most likely consequence, if any, would be an
incorrect result of some application dependent calculations or a crash
leading to a denial of service.
([CVE-2023-6129])
*Rohan McLure*
* Fix excessive time spent in DH check / generation with large Q parameter
value.
Applications that use the functions DH_generate_key() to generate an
X9.42 DH key may experience long delays. Likewise, applications that use
DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check()
to check an X9.42 DH key or X9.42 DH parameters may experience long delays.
Where the key or parameters that are being checked have been obtained from
an untrusted source this may lead to a Denial of Service.
([CVE-2023-5678])
*Richard Levitte*
* Disable building QUIC server utility when OpenSSL is configured with
`no-apps`.
*Vitalii Koshura*
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
openssl 3.x need correct arch configuration or disable
asm optimisation with no-asm config parameter.
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
- Update from version 3.1.4 to 3.2.0
- Update of rootfile
- Changelog
3.2.0
This release incorporates the following potentially significant or incompatible
changes:
* The default SSL/TLS security level has been changed from 1 to 2.
* The `x509`, `ca`, and `req` apps now always produce X.509v3 certificates.
* Subject or issuer names in X.509 objects are now displayed as UTF-8 strings
by default.
From my understanding these above changes should not create any problem for
IPFire.
This release adds the following new features:
* Support for client side QUIC, including support for
multiple streams (RFC 9000)
* Support for Ed25519ctx, Ed25519ph and Ed448ph in addition
to existing support for Ed25519 and Ed448 (RFC 8032)
* Support for deterministic ECDSA signatures (RFC 6979)
* Support for AES-GCM-SIV, a nonce-misuse-resistant AEAD (RFC 8452)
* Support for the Argon2 KDF, along with supporting thread pool
functionality (RFC 9106)
* Support for Hybrid Public Key Encryption (HPKE) (RFC 9180)
* Support for SM4-XTS
* Support for Brainpool curves in TLS 1.3
* Support for TLS Raw Public Keys (RFC 7250)
* Support for TCP Fast Open on Linux, macOS and FreeBSD,
where enabled and supported (RFC 7413)
* Support for TLS certificate compression, including library
support for zlib, Brotli and zstd (RFC 8879)
* Support for provider-based pluggable signature algorithms
in TLS 1.3 with supporting CMS and X.509 functionality
With a suitable provider this enables the use of post-quantum/quantum-safe
cryptography.
* Support for using the Windows system certificate store as a source of
trusted root certificates
This is not yet enabled by default and must be activated using an
environment variable. This is likely to become enabled by default
in a future feature release.
* Support for using the IANA standard names in TLS ciphersuite configuration
* Multiple new features and improvements to CMP protocol support
The following known issues are present in this release and will be rectified
in a future release:
* Provider-based signature algorithms cannot be configured using the
SignatureAlgorithms configuration file parameter (#22761)
This release incorporates the following documentation enhancements:
* Added multiple tutorials on the OpenSSL library and in particular
on writing various clients (using TLS and QUIC protocols) with libssl
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
* Fix excessive time spent checking DH q parameter value.
The function DH_check() performs various checks on DH parameters. After
fixing CVE-2023-3446 it was discovered that a large q parameter value can
also trigger an overly long computation during some of these checks.
A correct q value, if present, cannot be larger than the modulus p
parameter, thus it is unnecessary to perform these checks if q is larger
than p.
If DH_check() is called with such q parameter value,
DH_CHECK_INVALID_Q_VALUE return flag is set and the computationally
intensive checks are skipped.
([CVE-2023-3817])
*Tomáš Mráz*
* Fix DH_check() excessive time with over sized modulus.
The function DH_check() performs various checks on DH parameters. One of
those checks confirms that the modulus ("p" parameter) is not too large.
Trying to use a very large modulus is slow and OpenSSL will not normally use
a modulus which is over 10,000 bits in length.
However the DH_check() function checks numerous aspects of the key or
parameters that have been supplied. Some of those checks use the supplied
modulus value even if it has already been found to be too large.
A new limit has been added to DH_check of 32,768 bits. Supplying a
key/parameters with a modulus over this size will simply cause DH_check() to
fail.
([CVE-2023-3446])
*Matt Caswell*
* Do not ignore empty associated data entries with AES-SIV.
The AES-SIV algorithm allows for authentication of multiple associated
data entries along with the encryption. To authenticate empty data the
application has to call `EVP_EncryptUpdate()` (or `EVP_CipherUpdate()`)
with NULL pointer as the output buffer and 0 as the input buffer length.
The AES-SIV implementation in OpenSSL just returns success for such call
instead of performing the associated data authentication operation.
The empty data thus will not be authenticated. ([CVE-2023-2975])
Thanks to Juerg Wullschleger (Google) for discovering the issue.
The fix changes the authentication tag value and the ciphertext for
applications that use empty associated data entries with AES-SIV.
To decrypt data encrypted with previous versions of OpenSSL the application
has to skip calls to `EVP_DecryptUpdate()` for empty associated data
entries.
*Tomáš Mráz*
* When building with the `enable-fips` option and using the resulting
FIPS provider, TLS 1.2 will, by default, mandate the use of an extended
master secret (FIPS 140-3 IG G.Q) and the Hash and HMAC DRBGs will
not operate with truncated digests (FIPS 140-3 IG G.R).
*Paul Dale*
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
In a future Core Update, the following remnants of OpenSSL 1.1.1 need to
be removed:
/usr/lib/engines-1.1/afalg.so
/usr/lib/engines-1.1/capi.so
/usr/lib/engines-1.1/padlock.so
/usr/lib/libcrypto.so.1.1
/usr/lib/libssl.so.1.1
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
This removes support for building IPFire for 32 bit ARM architectures.
This has been decided in August 2022 with six months notice as there are
not very many users and hardware is generally not available any more.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
*) 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]
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- 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>
