Hi, On Tue, Oct 11, 2022 at 10:56:34PM +0200, Salvatore Bonaccorso wrote: > Source: openssl > Version: 3.0.5-4 > Severity: important > Tags: security upstream > X-Debbugs-Cc: car...@debian.org, Debian Security Team > <t...@security.debian.org> > Control: found -1 3.0.5-2 > > Hi, > > The following vulnerability was published for openssl. > > CVE-2022-3358[0]: > | OpenSSL supports creating a custom cipher via the legacy > | EVP_CIPHER_meth_new() function and associated function calls. This > | function was deprecated in OpenSSL 3.0 and application authors are > | instead encouraged to use the new provider mechanism in order to > | implement custom ciphers. OpenSSL versions 3.0.0 to 3.0.5 incorrectly > | handle legacy custom ciphers passed to the EVP_EncryptInit_ex2(), > | EVP_DecryptInit_ex2() and EVP_CipherInit_ex2() functions (as well as > | other similarly named encryption and decryption initialisation > | functions). Instead of using the custom cipher directly it incorrectly > | tries to fetch an equivalent cipher from the available providers. An > | equivalent cipher is found based on the NID passed to > | EVP_CIPHER_meth_new(). This NID is supposed to represent the unique > | NID for a given cipher. However it is possible for an application to > | incorrectly pass NID_undef as this value in the call to > | EVP_CIPHER_meth_new(). When NID_undef is used in this way the OpenSSL > | encryption/decryption initialisation function will match the NULL > | cipher as being equivalent and will fetch this from the available > | providers. This will succeed if the default provider has been loaded > | (or if a third party provider has been loaded that offers this > | cipher). Using the NULL cipher means that the plaintext is emitted as > | the ciphertext. Applications are only affected by this issue if they > | call EVP_CIPHER_meth_new() using NID_undef and subsequently use it in > | a call to an encryption/decryption initialisation function. > | Applications that only use SSL/TLS are not impacted by this issue. > | Fixed in OpenSSL 3.0.6 (Affected 3.0.0-3.0.5). > > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2022-3358 > https://www.cve.org/CVERecord?id=CVE-2022-3358 > [1] https://www.openssl.org/news/secadv/20221011.txt
As 3.0.6 has been retired due to regressions, I guess it's simply best to wait for 3.0.7. Regards, Salvatore
