https://github.com/openssl/openssl/commits/ and pick the appropriate
release branch.
+ Changes between 1.1.1v and 1.1.1w [11 Sep 2023]
+
+ *) Fix POLY1305 MAC implementation corrupting XMM registers on Windows.
+
+ The POLY1305 MAC (message authentication code) implementation in OpenSSL
+ does not save the contents of non-volatile XMM registers on Windows 64
+ platform when calculating the MAC of data larger than 64 bytes. Before
+ returning to the caller all the XMM registers are set to zero rather than
+ restoring their previous content. The vulnerable code is used only on newer
+ x86_64 processors supporting the AVX512-IFMA 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 given the contents of the registers are just
+ zeroized so the attacker cannot put arbitrary values inside, 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-4807)
+ [Bernd Edlinger]
+
+
+ Changes between 1.1.1u and 1.1.1v [1 Aug 2023]
+
+ *) 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]
+
+ Changes between 1.1.1t and 1.1.1u [30 May 2023]
+
+ *) Mitigate for the time it takes for `OBJ_obj2txt` to translate gigantic
+ OBJECT IDENTIFIER sub-identifiers to canonical numeric text form.
+
+ OBJ_obj2txt() would translate any size OBJECT IDENTIFIER to canonical
+ numeric text form. For gigantic sub-identifiers, this would take a very
+ long time, the time complexity being O(n^2) where n is the size of that
+ sub-identifier. (CVE-2023-2650)
+
+ To mitigitate this, `OBJ_obj2txt()` will only translate an OBJECT
+ IDENTIFIER to canonical numeric text form if the size of that OBJECT
+ IDENTIFIER is 586 bytes or less, and fail otherwise.
+
+ The basis for this restriction is RFC 2578 (STD 58), section 3.5. OBJECT
+ IDENTIFIER values, which stipulates that OBJECT IDENTIFIERS may have at
+ most 128 sub-identifiers, and that the maximum value that each sub-
+ identifier may have is 2^32-1 (4294967295 decimal).
+
+ For each byte of every sub-identifier, only the 7 lower bits are part of
+ the value, so the maximum amount of bytes that an OBJECT IDENTIFIER with
+ these restrictions may occupy is 32 * 128 / 7, which is approximately 586
+ bytes.
+
+ Ref: https://datatracker.ietf.org/doc/html/rfc2578#section-3.5
+
+ [Richard Levitte]
+
+ *) Reworked the Fix for the Timing Oracle in RSA Decryption (CVE-2022-4304).
+ The previous fix for this timing side channel turned out to cause
+ a severe 2-3x performance regression in the typical use case
+ compared to 1.1.1s. The new fix uses existing constant time
+ code paths, and restores the previous performance level while
+ fully eliminating all existing timing side channels.
+ The fix was developed by Bernd Edlinger with testing support
+ by Hubert Kario.
+ [Bernd Edlinger]
+
+ *) Corrected documentation of X509_VERIFY_PARAM_add0_policy() to mention
+ that it does not enable policy checking. Thanks to
+ David Benjamin for discovering this issue. (CVE-2023-0466)
+ [Tomas Mraz]
+
+ *) Fixed an issue where invalid certificate policies in leaf certificates are
+ silently ignored by OpenSSL and other certificate policy checks are skipped
+ for that certificate. A malicious CA could use this to deliberately assert
+ invalid certificate policies in order to circumvent policy checking on the
+ certificate altogether. (CVE-2023-0465)
+ [Matt Caswell]
+
+ *) Limited the number of nodes created in a policy tree to mitigate
+ against CVE-2023-0464. The default limit is set to 1000 nodes, which
+ should be sufficient for most installations. If required, the limit
+ can be adjusted by setting the OPENSSL_POLICY_TREE_NODES_MAX build
+ time define to a desired maximum number of nodes or zero to allow
+ unlimited growth. (CVE-2023-0464)
+ [Paul Dale]
+
+ Changes between 1.1.1s and 1.1.1t [7 Feb 2023]
+
+ *) Fixed X.400 address type confusion in X.509 GeneralName.
+
+ There is a type confusion vulnerability relating to X.400 address processing
+ inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING
+ but subsequently interpreted by GENERAL_NAME_cmp as an ASN1_TYPE. This
+ vulnerability may allow an attacker who can provide a certificate chain and
+ CRL (neither of which need have a valid signature) to pass arbitrary
+ pointers to a memcmp call, creating a possible read primitive, subject to
+ some constraints. Refer to the advisory for more information. Thanks to
+ David Benjamin for discovering this issue. (CVE-2023-0286)
+
+ This issue has been fixed by changing the public header file definition of
+ GENERAL_NAME so that x400Address reflects the implementation. It was not
+ possible for any existing application to successfully use the existing
+ definition; however, if any application references the x400Address field
+ (e.g. in dead code), note that the type of this field has changed. There is
+ no ABI change.
+ [Hugo Landau]
+
+ *) Fixed Use-after-free following BIO_new_NDEF.
+
+ The public API function BIO_new_NDEF is a helper function used for
+ streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL
+ to support the SMIME, CMS and PKCS7 streaming capabilities, but may also
+ be called directly by end user applications.
+
+ The function receives a BIO from the caller, prepends a new BIO_f_asn1
+ filter BIO onto the front of it to form a BIO chain, and then returns
+ the new head of the BIO chain to the caller. Under certain conditions,
+ for example if a CMS recipient public key is invalid, the new filter BIO
+ is freed and the function returns a NULL result indicating a failure.
+ However, in this case, the BIO chain is not properly cleaned up and the
+ BIO passed by the caller still retains internal pointers to the previously
+ freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO
+ then a use-after-free will occur. This will most likely result in a crash.
+ (CVE-2023-0215)
+ [Viktor Dukhovni, Matt Caswell]
+
+ *) Fixed Double free after calling PEM_read_bio_ex.
+
+ The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and
+ decodes the "name" (e.g. "CERTIFICATE"), any header data and the payload
+ data. If the function succeeds then the "name_out", "header" and "data"
+ arguments are populated with pointers to buffers containing the relevant
+ decoded data. The caller is responsible for freeing those buffers. It is
+ possible to construct a PEM file that results in 0 bytes of payload data.
+ In this case PEM_read_bio_ex() will return a failure code but will populate
+ the header argument with a pointer to a buffer that has already been freed.
+ If the caller also frees this buffer then a double free will occur. This
+ will most likely lead to a crash.
+
+ The functions PEM_read_bio() and PEM_read() are simple wrappers around
+ PEM_read_bio_ex() and therefore these functions are also directly affected.
+
+ These functions are also called indirectly by a number of other OpenSSL
+ functions including PEM_X509_INFO_read_bio_ex() and
+ SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL
+ internal uses of these functions are not vulnerable because the caller does
+ not free the header argument if PEM_read_bio_ex() returns a failure code.
+ (CVE-2022-4450)
+ [Kurt Roeckx, Matt Caswell]
+
+ *) Fixed Timing Oracle in RSA Decryption.
+
+ A timing based side channel exists in the OpenSSL RSA Decryption
+ implementation which could be sufficient to recover a plaintext across
+ a network in a Bleichenbacher style attack. To achieve a successful
+ decryption an attacker would have to be able to send a very large number
+ of trial messages for decryption. The vulnerability affects all RSA padding
+ modes: PKCS#1 v1.5, RSA-OEAP and RSASVE.
+ (CVE-2022-4304)
+ [Dmitry Belyavsky, Hubert Kario]
+
+ Changes between 1.1.1r and 1.1.1s [1 Nov 2022]
+
+ *) Fixed a regression introduced in 1.1.1r version not refreshing the
+ certificate data to be signed before signing the certificate.
+ [Gibeom Gwon]
+
+ Changes between 1.1.1q and 1.1.1r [11 Oct 2022]
+
+ *) Fixed the linux-mips64 Configure target which was missing the
+ SIXTY_FOUR_BIT bn_ops flag. This was causing heap corruption on that
+ platform.
+ [Adam Joseph]
+
+ *) Fixed a strict aliasing problem in bn_nist. Clang-14 optimisation was
+ causing incorrect results in some cases as a result.
+ [Paul Dale]
+
+ *) Fixed SSL_pending() and SSL_has_pending() with DTLS which were failing to
+ report correct results in some cases
+ [Matt Caswell]
+
+ *) Fixed a regression introduced in 1.1.1o for re-signing certificates with
+ different key sizes
+ [Todd Short]
+
+ *) Added the loongarch64 target
+ [Shi Pujin]
+
+ *) Fixed a DRBG seed propagation thread safety issue
+ [Bernd Edlinger]
+
+ *) Fixed a memory leak in tls13_generate_secret
+ [Bernd Edlinger]
+
+ *) Fixed reported performance degradation on aarch64. Restored the
+ implementation prior to commit 2621751 ("aes/asm/aesv8-armx.pl: avoid
+ 32-bit lane assignment in CTR mode") for 64bit targets only, since it is
+ reportedly 2-17% slower and the silicon errata only affects 32bit targets.
+ The new algorithm is still used for 32 bit targets.
+ [Bernd Edlinger]
+
+ *) Added a missing header for memcmp that caused compilation failure on some
+ platforms
+ [Gregor Jasny]
+
+ Changes between 1.1.1p and 1.1.1q [5 Jul 2022]
+
+ *) 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.
+ (CVE-2022-2097)
+ [Alex Chernyakhovsky, David Benjamin, Alejandro Sedeño]
+
+ Changes between 1.1.1o and 1.1.1p [21 Jun 2022]
+
+ *) In addition to the c_rehash shell command injection identified in
+ CVE-2022-1292, further bugs where the c_rehash script does not
+ properly sanitise shell metacharacters to prevent command injection have been
+ fixed.
+
+ When the CVE-2022-1292 was fixed it was not discovered that there
+ are other places in the script where the file names of certificates
+ being hashed were possibly passed to a command executed through the shell.
+
+ 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.
+ (CVE-2022-2068)
+ [Daniel Fiala, Tomáš Mráz]
+
+ *) When OpenSSL TLS client is connecting without any supported elliptic
+ curves and TLS-1.3 protocol is disabled the connection will no longer fail
+ if a ciphersuite that does not use a key exchange based on elliptic
+ curves can be negotiated.
+ [Tomáš Mráz]
+
+ Changes between 1.1.1n and 1.1.1o [3 May 2022]
+
+ *) 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.
+ (CVE-2022-1292)
+ [Tomáš Mráz]
+
+ Changes between 1.1.1m and 1.1.1n [15 Mar 2022]
+
+ *) Fixed a bug in the BN_mod_sqrt() function 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.
+ (CVE-2022-0778)
+ [Tomáš Mráz]
+
+ *) Add ciphersuites based on DHE_PSK (RFC 4279) and ECDHE_PSK (RFC 5489)
+ to the list of ciphersuites providing Perfect Forward Secrecy as
+ required by SECLEVEL >= 3.
+
+ [Dmitry Belyavskiy, Nicola Tuveri]
+
+ 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]
+
+ Changes between 1.1.1k and 1.1.1l [24 Aug 2021]
+
+ *) Fixed an SM2 Decryption Buffer Overflow.
+
+ In order to decrypt SM2 encrypted data an application is expected to call the
+ API function EVP_PKEY_decrypt(). Typically an application will call this
+ function twice. The first time, on entry, the "out" parameter can be NULL and,
+ on exit, the "outlen" parameter is populated with the buffer size required to
+ hold the decrypted plaintext. The application can then allocate a sufficiently
+ sized buffer and call EVP_PKEY_decrypt() again, but this time passing a non-NULL
+ value for the "out" parameter.
+
+ A bug in the implementation of the SM2 decryption code means that the
+ calculation of the buffer size required to hold the plaintext returned by the
+ first call to EVP_PKEY_decrypt() can be smaller than the actual size required by
+ the second call. This can lead to a buffer overflow when EVP_PKEY_decrypt() is
+ called by the application a second time with a buffer that is too small.
+
+ A malicious attacker who is able present SM2 content for decryption to an
+ application could cause attacker chosen data to overflow the buffer by up to a
+ maximum of 62 bytes altering the contents of other data held after the
+ buffer, possibly changing application behaviour or causing the application to
+ crash. The location of the buffer is application dependent but is typically
+ heap allocated.
+ (CVE-2021-3711)
+ [Matt Caswell]
+
+ *) Fixed various read buffer overruns processing ASN.1 strings
+
+ ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING
+ structure which contains a buffer holding the string data and a field holding
+ the buffer length. This contrasts with normal C strings which are repesented as
+ a buffer for the string data which is terminated with a NUL (0) byte.
+
+ Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's
+ own "d2i" functions (and other similar parsing functions) as well as any string
+ whose value has been set with the ASN1_STRING_set() function will additionally
+ NUL terminate the byte array in the ASN1_STRING structure.
+
+ However, it is possible for applications to directly construct valid ASN1_STRING
+ structures which do not NUL terminate the byte array by directly setting the
+ "data" and "length" fields in the ASN1_STRING array. This can also happen by
+ using the ASN1_STRING_set0() function.
+
+ Numerous OpenSSL functions that print ASN.1 data have been found to assume that
+ the ASN1_STRING byte array will be NUL terminated, even though this is not
+ guaranteed for strings that have been directly constructed. Where an application
+ requests an ASN.1 structure to be printed, and where that ASN.1 structure
+ contains ASN1_STRINGs that have been directly constructed by the application
+ without NUL terminating the "data" field, then a read buffer overrun can occur.
+
+ The same thing can also occur during name constraints processing of certificates
+ (for example if a certificate has been directly constructed by the application
+ instead of loading it via the OpenSSL parsing functions, and the certificate
+ contains non NUL terminated ASN1_STRING structures). It can also occur in the
+ X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions.
+
+ If a malicious actor can cause an application to directly construct an
+ ASN1_STRING and then process it through one of the affected OpenSSL functions
+ then this issue could be hit. This might result in a crash (causing a Denial of
+ Service attack). It could also result in the disclosure of private memory
+ contents (such as private keys, or sensitive plaintext).
+ (CVE-2021-3712)
+ [Matt Caswell]
+
+ 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]
+
Changes between 1.1.1i and 1.1.1j [16 Feb 2021]
*) Fixed the X509_issuer_and_serial_hash() function. It attempts to
projects / platform / upstream / openssl1.1.git / blobdiff