|
7 | 7 | https://github.com/openssl/openssl/commits/ and pick the appropriate |
8 | 8 | release branch. |
9 | 9 |
|
| 10 | + Changes between 1.1.1s and 1.1.1t [7 Feb 2023] |
| 11 | + |
| 12 | + *) Fixed X.400 address type confusion in X.509 GeneralName. |
| 13 | + |
| 14 | + There is a type confusion vulnerability relating to X.400 address processing |
| 15 | + inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING |
| 16 | + but subsequently interpreted by GENERAL_NAME_cmp as an ASN1_TYPE. This |
| 17 | + vulnerability may allow an attacker who can provide a certificate chain and |
| 18 | + CRL (neither of which need have a valid signature) to pass arbitrary |
| 19 | + pointers to a memcmp call, creating a possible read primitive, subject to |
| 20 | + some constraints. Refer to the advisory for more information. Thanks to |
| 21 | + David Benjamin for discovering this issue. (CVE-2023-0286) |
| 22 | + |
| 23 | + This issue has been fixed by changing the public header file definition of |
| 24 | + GENERAL_NAME so that x400Address reflects the implementation. It was not |
| 25 | + possible for any existing application to successfully use the existing |
| 26 | + definition; however, if any application references the x400Address field |
| 27 | + (e.g. in dead code), note that the type of this field has changed. There is |
| 28 | + no ABI change. |
| 29 | + [Hugo Landau] |
| 30 | + |
| 31 | + *) Fixed Use-after-free following BIO_new_NDEF. |
| 32 | + |
| 33 | + The public API function BIO_new_NDEF is a helper function used for |
| 34 | + streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL |
| 35 | + to support the SMIME, CMS and PKCS7 streaming capabilities, but may also |
| 36 | + be called directly by end user applications. |
| 37 | + |
| 38 | + The function receives a BIO from the caller, prepends a new BIO_f_asn1 |
| 39 | + filter BIO onto the front of it to form a BIO chain, and then returns |
| 40 | + the new head of the BIO chain to the caller. Under certain conditions, |
| 41 | + for example if a CMS recipient public key is invalid, the new filter BIO |
| 42 | + is freed and the function returns a NULL result indicating a failure. |
| 43 | + However, in this case, the BIO chain is not properly cleaned up and the |
| 44 | + BIO passed by the caller still retains internal pointers to the previously |
| 45 | + freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO |
| 46 | + then a use-after-free will occur. This will most likely result in a crash. |
| 47 | + (CVE-2023-0215) |
| 48 | + [Viktor Dukhovni, Matt Caswell] |
| 49 | + |
| 50 | + *) Fixed Double free after calling PEM_read_bio_ex. |
| 51 | + |
| 52 | + The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and |
| 53 | + decodes the "name" (e.g. "CERTIFICATE"), any header data and the payload |
| 54 | + data. If the function succeeds then the "name_out", "header" and "data" |
| 55 | + arguments are populated with pointers to buffers containing the relevant |
| 56 | + decoded data. The caller is responsible for freeing those buffers. It is |
| 57 | + possible to construct a PEM file that results in 0 bytes of payload data. |
| 58 | + In this case PEM_read_bio_ex() will return a failure code but will populate |
| 59 | + the header argument with a pointer to a buffer that has already been freed. |
| 60 | + If the caller also frees this buffer then a double free will occur. This |
| 61 | + will most likely lead to a crash. |
| 62 | + |
| 63 | + The functions PEM_read_bio() and PEM_read() are simple wrappers around |
| 64 | + PEM_read_bio_ex() and therefore these functions are also directly affected. |
| 65 | + |
| 66 | + These functions are also called indirectly by a number of other OpenSSL |
| 67 | + functions including PEM_X509_INFO_read_bio_ex() and |
| 68 | + SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL |
| 69 | + internal uses of these functions are not vulnerable because the caller does |
| 70 | + not free the header argument if PEM_read_bio_ex() returns a failure code. |
| 71 | + (CVE-2022-4450) |
| 72 | + [Kurt Roeckx, Matt Caswell] |
| 73 | + |
| 74 | + *) Fixed Timing Oracle in RSA Decryption. |
| 75 | + |
| 76 | + A timing based side channel exists in the OpenSSL RSA Decryption |
| 77 | + implementation which could be sufficient to recover a plaintext across |
| 78 | + a network in a Bleichenbacher style attack. To achieve a successful |
| 79 | + decryption an attacker would have to be able to send a very large number |
| 80 | + of trial messages for decryption. The vulnerability affects all RSA padding |
| 81 | + modes: PKCS#1 v1.5, RSA-OEAP and RSASVE. |
| 82 | + (CVE-2022-4304) |
| 83 | + [Dmitry Belyavsky, Hubert Kario] |
| 84 | + |
10 | 85 | Changes between 1.1.1r and 1.1.1s [1 Nov 2022] |
11 | 86 |
|
12 | 87 | *) Fixed a regression introduced in 1.1.1r version not refreshing the |
13 | 88 | certificate data to be signed before signing the certificate. |
14 | | - |
15 | 89 | [Gibeom Gwon] |
16 | 90 |
|
17 | 91 | Changes between 1.1.1q and 1.1.1r [11 Oct 2022] |
|
0 commit comments