Upgrade to openssl 1.1.1w
[platform/upstream/openssl1.1.git] / CHANGES
diff --git a/CHANGES b/CHANGES
index c18a1f5..c440948 100644 (file)
--- a/CHANGES
+++ b/CHANGES
@@ -7,6 +7,243 @@
  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