CVE-2022-3358

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).

Bugs

• <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021620&gt;

Notes