gcc on solaris/illumos defines __STDC_VERSION__ in c++ mode where _Noreturn
does not exist.
This causes breakage when building c++17 programs that use openssl.
Approved by @wiz during freeze.
Changes between 1.1.1j and 1.1.1k [25 Mar 2021]
*) Fixed a problem with verifying a certificate chain when using the
X509_V_FLAG_X509_STRICT flag. This 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.
(CVE-2021-3450)
[Tomáš Mráz]
*) Fixed an issue where 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.
(CVE-2021-3449)
[Peter Kästle and Samuel Sapalski]
Some systems choose unusual paths fro certs, and some use bundles.
Try to accomodate that, in particular by defining SSLCERTBUNDLE.
Patch concept from Thomas Orgis on tech-pkg, with no objections.
Major changes between OpenSSL 1.1.1i and OpenSSL 1.1.1j [16 Feb 2021]
o Fixed a NULL pointer deref in the X509_issuer_and_serial_hash()
function (CVE-2021-23841)
o Fixed the RSA_padding_check_SSLv23() function and the RSA_SSLV23_PADDING
padding mode to correctly check for rollback attacks
o Fixed an overflow in the EVP_CipherUpdate, EVP_EncryptUpdate and
EVP_DecryptUpdate functions (CVE-2021-23840)
o Fixed SRP_Calc_client_key so that it runs in constant time
Major changes between OpenSSL 1.1.1g and OpenSSL 1.1.1h [22 Sep 2020]
o Disallow explicit curve parameters in verifications chains when
X509_V_FLAG_X509_STRICT is used
o Enable 'MinProtocol' and 'MaxProtocol' to configure both TLS and DTLS
contexts
o Oracle Developer Studio will start reporting deprecation warnings
(1) There is no {get,make,set}context support before Darwin 9
(2) Instead of failing the build on makedepend(8) malfunction, have
make(1) ignore its return value - which used to be the default for
previous OpenSSL versions.
Adding --libdir seems innocuous enough, but due to OpenSSL's crazy complicated
build system actually results in LIBDIR becoming unset, which trickles down to
the Darwin -install_name being wrong. This broke the 'openssl' command and
thus many many dependencies.
Switch to $(libdir) instead which appears to still be set correctly.
Major changes between OpenSSL 1.1.1d and OpenSSL 1.1.1e [17 Mar 2020]
o Fixed an overflow bug in the x64_64 Montgomery squaring procedure
used in exponentiation with 512-bit moduli (CVE-2019-1551)
This is a major upgrade to the current LTS release. 1.0.2 and 1.1.0 are now
out of support and should not be used.
pkgsrc changes include a large cleanup of patches and targets, many of which
were clearly bogus, for example a CONFLICTS entry against a package that has
never existed, and one that was removed in 1999.
Tested on SmartOS, macOS, and NetBSD. Used for the SmartOS pkgsrc-2019Q4 LTS
release.
There are far too many individual changes to list, so the following text is
instead taken from the 1.1.1 blog announcement:
--------------------------------------------------------------------------
After two years of work we are excited to be releasing our latest version today
- OpenSSL 1.1.1. This is also our new Long Term Support (LTS) version and so we
are committing to support it for at least five years.
OpenSSL 1.1.1 has been a huge team effort with nearly 5000 commits having been
made from over 200 individual contributors since the release of OpenSSL 1.1.0.
These statistics just illustrate the amazing vitality and diversity of the
OpenSSL community. The contributions didn't just come in the form of commits
though. There has been a great deal of interest in this new version so thanks
needs to be extended to the large number of users who have downloaded the beta
releases to test them out and report bugs.
The headline new feature is TLSv1.3. This new version of the Transport Layer
Security (formerly known as SSL) protocol was published by the IETF just one
month ago as RFC8446. This is a major rewrite of the standard and introduces
significant changes, features and improvements which have been reflected in the
new OpenSSL version.
What's more is that OpenSSL 1.1.1 is API and ABI compliant with OpenSSL 1.1.0
so most applications that work with 1.1.0 can gain many of the benefits of
TLSv1.3 simply by dropping in the new OpenSSL version. Since TLSv1.3 works very
differently to TLSv1.2 though there are a few caveats that may impact a
minority of applications. See the TLSv1.3 page on the OpenSSL wiki for more
details.
Some of the benefits of TLSv1.3 include:
* Improved connection times due to a reduction in the number of round trips
required between the client and server
* The ability, in certain circumstances, for clients to start sending
encrypted data to the server straight away without any round trips with the
server required (a feature known as 0-RTT or “early data”).
* Improved security due to the removal of various obsolete and insecure
cryptographic algorithms and encryption of more of the connection handshake
Other features in the 1.1.1 release include:
* Complete rewrite of the OpenSSL random number generator to introduce the
following capabilities:
* The default RAND method now utilizes an AES-CTR DRBG according to NIST
standard SP 800-90Ar1.
* Support for multiple DRBG instances with seed chaining.
* There is a public and private DRBG instance.
* The DRBG instances are fork-safe.
* Keep all global DRBG instances on the secure heap if it is enabled.
* The public and private DRBG instance are per thread for lock free
operation
* Support for various new cryptographic algorithms including:
* SHA3
* SHA512/224 and SHA512/256
* EdDSA (including Ed25519 and Ed448)
* X448 (adding to the existing X25519 support in 1.1.0)
* Multi-prime RSA
* SM2
* SM3
* SM4
* SipHash
* ARIA (including TLS support)
* Signficant Side-Channel attack security improvements
* Maximum Fragment Length TLS extension support
* A new STORE module, which implements a uniform and URI based reader of
stores that can contain keys, certificates, CRLs and numerous other objects.
Since 1.1.1 is our new LTS release we are strongly advising all users to
upgrade as soon as possible. For most applications this should be straight
forward if they are written to work with OpenSSL 1.1.0. Since OpenSSL 1.1.0 is
not an LTS release it will start receiving security fixes only with immediate
affect as per our previous announcement and as published in our release
strategy. It will cease receiving all support in one years time.
Our previous LTS release (OpenSSL 1.0.2) will continue to receive full support
until the end of this year. After that it will receive security fixes only. It
will stop receiving all support at the end of 2019. Users of that release are
strongly advised to upgrade to OpenSSL 1.1.1.
Major changes between OpenSSL 1.0.2t and OpenSSL 1.0.2u [20 Dec 2019]
Fixed an an overflow bug in the x64_64 Montgomery squaring procedure used
in exponentiation with 512-bit moduli (CVE-2019-1551)
Changes between 1.0.2s and 1.0.2t [10 Sep 2019]
*) For built-in EC curves, ensure an EC_GROUP built from the curve name is
used even when parsing explicit parameters, when loading a serialized key
or calling `EC_GROUP_new_from_ecpkparameters()`/
`EC_GROUP_new_from_ecparameters()`.
This prevents bypass of security hardening and performance gains,
especially for curves with specialized EC_METHODs.
By default, if a key encoded with explicit parameters is loaded and later
serialized, the output is still encoded with explicit parameters, even if
internally a "named" EC_GROUP is used for computation.
[Nicola Tuveri]
*) Compute ECC cofactors if not provided during EC_GROUP construction. Before
this change, EC_GROUP_set_generator would accept order and/or cofactor as
NULL. After this change, only the cofactor parameter can be NULL. It also
does some minimal sanity checks on the passed order.
(CVE-2019-1547)
[Billy Bob Brumley]
*) Fixed a padding oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey.
An attack is simple, if the first CMS_recipientInfo is valid but the
second CMS_recipientInfo is chosen ciphertext. If the second
recipientInfo decodes to PKCS #1 v1.5 form plaintext, the correct
encryption key will be replaced by garbage, and the message cannot be
decoded, but if the RSA decryption fails, the correct encryption key is
used and the recipient will not notice the attack.
As a work around for this potential attack the length of the decrypted
key must be equal to the cipher default key length, in case the
certifiate is not given and all recipientInfo are tried out.
The old behaviour can be re-enabled in the CMS code by setting the
CMS_DEBUG_DECRYPT flag.
(CVE-2019-1563)
[Bernd Edlinger]
*) Document issue with installation paths in diverse Windows builds
'/usr/local/ssl' is an unsafe prefix for location to install OpenSSL
binaries and run-time config file.
(CVE-2019-1552)
[Richard Levitte]
Tested on OS X Tiger PowerPC and NetBSD-HEAD amd64
Changes between 1.0.2r and 1.0.2s [28 May 2019]
*) Change the default RSA, DSA and DH size to 2048 bit instead of 1024.
This changes the size when using the genpkey app when no size is given. It
fixes an omission in earlier changes that changed all RSA, DSA and DH
generation apps to use 2048 bits by default.
[Kurt Roeckx]
*) Add FIPS support for Android Arm 64-bit
Support for Android Arm 64-bit was added to the OpenSSL FIPS Object
Module in Version 2.0.10. For some reason, the corresponding target
'android64-aarch64' was missing OpenSSL 1.0.2, whence it could not be
built with FIPS support on Android Arm 64-bit. This omission has been
fixed.
[Matthias St. Pierre]
Changes between 1.0.2q and 1.0.2r [26 Feb 2019]
*) 0-byte record padding oracle
If an application encounters a fatal protocol error and then calls
SSL_shutdown() twice (once to send a close_notify, and once to receive one)
then OpenSSL can respond differently to the calling application if a 0 byte
record is received with invalid padding compared to if a 0 byte record is
received with an invalid MAC. If the application then behaves differently
based on that in a way that is detectable to the remote peer, then this
amounts to a padding oracle that could be used to decrypt data.
In order for this to be exploitable "non-stitched" ciphersuites must be in
use. Stitched ciphersuites are optimised implementations of certain
commonly used ciphersuites. Also the application must call SSL_shutdown()
twice even if a protocol error has occurred (applications should not do
this but some do anyway).
This issue was discovered by Juraj Somorovsky, Robert Merget and Nimrod
Aviram, with additional investigation by Steven Collison and Andrew
Hourselt. It was reported to OpenSSL on 10th December 2018.
(CVE-2019-1559)
[Matt Caswell]
*) Move strictness check from EVP_PKEY_asn1_new() to EVP_PKEY_asn1_add0().
[Richard Levitte]
Changes between 1.0.2p and 1.0.2q [20 Nov 2018]
*) Microarchitecture timing vulnerability in ECC scalar multiplication
OpenSSL ECC scalar multiplication, used in e.g. ECDSA and ECDH, has been
shown to be vulnerable to a microarchitecture timing side channel attack.
An attacker with sufficient access to mount local timing attacks during
ECDSA signature generation could recover the private key.
This issue was reported to OpenSSL on 26th October 2018 by Alejandro
Cabrera Aldaya, Billy Brumley, Sohaib ul Hassan, Cesar Pereida Garcia and
Nicola Tuveri.
(CVE-2018-5407)
[Billy Brumley]
*) 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]
*) Resolve a compatibility issue in EC_GROUP handling with the FIPS Object
Module, accidentally introduced while backporting security fixes from the
development branch and hindering the use of ECC in FIPS mode.
[Nicola Tuveri]
- 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]
Changes between 1.0.2n and 1.0.2o [27 Mar 2018]
*) Constructed ASN.1 types with a recursive definition could exceed the stack
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.
This issue was reported to OpenSSL on 4th January 2018 by the OSS-fuzz
project.
(CVE-2018-0739)
[Matt Caswell]
The actual fix as been done by "pkglint -F */*/buildlink3.mk", and was
reviewed manually.
There are some .include lines that still are indented with zero spaces
although the surrounding .if is indented. This is existing practice.
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.
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).
This is a recommended security update.
Changes between 1.0.2l and 1.0.2m [2 Nov 2017]
*) bn_sqrx8x_internal carry bug on x86_64
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.
This only affects processors that support the BMI1, BMI2 and ADX extensions
like Intel Broadwell (5th generation) and later or AMD Ryzen.
This issue was reported to OpenSSL by the OSS-Fuzz project.
(CVE-2017-3736)
[Andy Polyakov]
*) Malformed X.509 IPAddressFamily could cause OOB read
If an X.509 certificate has a malformed IPAddressFamily extension,
OpenSSL could do a one-byte buffer overread. The most likely result
would be an erroneous display of the certificate in text format.
This issue was reported to OpenSSL by the OSS-Fuzz project.
(CVE-2017-3735)
[Rich Salz]
Changes between 1.0.2k and 1.0.2l [25 May 2017]
*) Have 'config' recognise 64-bit mingw and choose 'mingw64' as the target
platform rather than 'mingw'.
[Richard Levitte]
