CVE-2022-3358
published 2022-10-11CVE-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…
PriorityP351high7.5CVSS 3.1
AVNACLPRNUINSUCHINAN
EXPLOIT
EPSS
2.85%
84.9th percentile
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).
Affected
9 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | openssl | < openssl 3.0.7-1 (bookworm) | openssl 3.0.7-1 (bookworm) |
| horovod | horovod | >= 0 < 0.24.0 | 0.24.0 |
| openssl | openssl | — | — |
| openssl | openssl | >= 0 < 3.0.7-1 | 3.0.7-1 |
| openssl | openssl | >= 0 < 3.0.7-1 | 3.0.7-1 |
| openssl | openssl | >= 0 < 3.0.7-1 | 3.0.7-1 |
| openssl | openssl | >= 0 < 3.0.2-0ubuntu1.7 | 3.0.2-0ubuntu1.7 |
| openssl | openssl | >= 3.0.0 < 3.0.6 | 3.0.6 |
| paloalto | pan-os | — | — |
Detection & IOCsextracted from sources · hover to see the quote
- →Applications calling EVP_CIPHER_meth_new() with NID_undef and passing the result to encryption/decryption init functions (EVP_EncryptInit_ex2, EVP_DecryptInit_ex2, EVP_CipherInit_ex2) will silently use the NULL cipher, emitting plaintext as ciphertext — audit code or logs for unexpected unencrypted traffic from OpenSSL 3.0.0–3.0.5 applications. ↗
- →Affected OpenSSL versions are strictly 3.0.0 through 3.0.5; OpenSSL 1.0.x (shipped in RHEL 6/7/8) does not contain the vulnerable code path and is not affected. ↗
- →SSL/TLS-only applications are not affected; focus detection efforts on applications using the legacy EVP_CIPHER_meth_new() API directly with custom cipher implementations. ↗
- →The NULL cipher will only be fetched (and the vulnerability triggered) if the default OpenSSL provider or a third-party provider offering the NULL cipher has been loaded — check provider configuration in affected deployments. ↗
- ·Red Hat Enterprise Linux 6, 7, and 8 ship OpenSSL 1.0 which does not contain the vulnerable code and are not affected. ↗
- ·The vulnerability only manifests when an application incorrectly passes NID_undef to EVP_CIPHER_meth_new(); correctly implemented custom ciphers using valid NIDs are not affected. ↗
CVSS provenance
nvdv3.17.5HIGHCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
osv7.5HIGH
vendor_debian7.5HIGH
vendor_redhat7.5HIGH
vendor_ubuntu7.5HIGH
CVEs like this are exactly what “Exploited This Week” covers.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
OSV
openssl vulnerabilities
osv·2022-11-01·CVSS 7.5
CVE-2022-3602 [HIGH] openssl vulnerabilities
openssl vulnerabilities
It was discovered that OpenSSL incorrectly handled certain X.509 Email
Addresses. If a certificate authority were tricked into signing a
specially-crafted certificate, a remote attacker could possibly use this
issue to cause OpenSSL to crash, resulting in a denial of service. The
default compiler options for affected releases reduce the vulnerability to
a denial of service. (CVE-2022-3602, CVE-2022-3786)
It was discovered that OpenSSL incorrectly handled applications creating
custom ciphers via the legacy EVP_CIPHER_meth_new() function. This issue
could cause certain applications that mishandled values to the function to
possibly end up with a NULL cipher and messages in plaintext.
(CVE-2022-3358)
GHSA
Using a Custom Cipher with `NID_undef` may lead to NULL encryption
ghsa·2022-10-11
CVE-2022-3358 [HIGH] CWE-476 Using a Custom Cipher with `NID_undef` may lead to NULL encryption
Using a Custom Cipher with `NID_undef` may lead to NULL encryption
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_met
OSV
Using a Custom Cipher with `NID_undef` may lead to NULL encryption
osv·2022-10-11
CVE-2022-3358 Using a Custom Cipher with `NID_undef` may lead to NULL encryption
Using a Custom Cipher with `NID_undef` may lead to NULL encryption
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_
OSV
CVE-2022-3358: OpenSSL supports creating a custom cipher via the legacy EVP_CIPHER_meth_new() function and associated function calls
osv·2022-10-11·CVSS 7.5
CVE-2022-3358 [HIGH] CVE-2022-3358: OpenSSL supports creating a custom cipher via the legacy EVP_CIPHER_meth_new() function and associated function calls
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 give
OSV
Using a Custom Cipher with `NID_undef` may lead to NULL encryption
osv·2022-10-11
CVE-2022-3358 [HIGH] Using a Custom Cipher with `NID_undef` may lead to NULL encryption
Using a Custom Cipher with `NID_undef` may lead to NULL encryption
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_met
GHSA
Use of insecure temporary file in Horovod
ghsa·2022-03-29
CVE-2022-0315 [HIGH] CWE-377 Use of insecure temporary file in Horovod
Use of insecure temporary file in Horovod
### Impact
The insecure `tempfile.mktemp()` is used when Horovod is run in an LSF job with `jsrun`. In that situation, a jsrun rank file is created with `mktemp`, which could be hijacked by another process to read or manipulate the content.
This issue does not impact the use of MPI, Gloo, Spark or Ray.
### Patches
The problem has been fixed in [b96ecae4](https://github.com/horovod/horovod/commit/b96ecae4dc69fc0a83c7c2d3f1dde600c20a1b41).
### Workarounds
The rank file is not created when `binding_args` are provided in the `Settings` instance.
### References
Please see https://github.com/horovod/horovod/pull/3358 for details.
### For more information
If you have any questions or comments about this advisory:
* Open an issue in [https://github.c
Palo Alto
PAN-SA-2024-0008 Informational Bulletin: Impact of OSS CVEs in PAN-OS
vendor_paloalto·2024-09-04·CVSS 6.0
CVE-2010-1622 [MEDIUM] PAN-SA-2024-0008 Informational Bulletin: Impact of OSS CVEs in PAN-OS
PAN-SA-2024-0008 Informational Bulletin: Impact of OSS CVEs in PAN-OS
The Palo Alto Networks Product Security Assurance team has evaluated the following open source software (OSS) CVEs as they relate to PAN-OS software. While PAN-OS software may include the
CVEs: CVE-2010-1622, CVE-2015-7552, CVE-2018-16840, CVE-2019-7639, CVE-2020-17049, CVE-2020-7774, CVE-2021-0131, CVE-2021-0132, CVE-2021-0133, CVE-2021-0134, CVE-2021-4044, CVE-2021-4160, CVE-2021-41773, CVE-2022-1343, CVE-2022-21449, CVE-2022-2274, CVE-2022-22963, CVE-2022-22965, CVE-2022-24697, CVE-2022-32207, CVE-2022-3358, CVE-2022-3996, CVE-2022-40664, CVE-2022-44792, CVE-2022-44793, CVE-2023-1255, CVE-2023-22809, CVE-2023-23919, CVE-2023-3341, CVE-2023-4236, CVE-2023-4863, CVE-2023-51767
Affected products: PAN-OS
Palo Alto
PAN-SA-2024-0008 Informational Bulletin: Impact of OSS CVEs in PAN-OS
vendor_paloalto·2024-09-04·CVSS 6.0
CVE-2022-22965 [MEDIUM] PAN-SA-2024-0008 Informational Bulletin: Impact of OSS CVEs in PAN-OS
PAN-SA-2024-0008 Informational Bulletin: Impact of OSS CVEs in PAN-OS
The Palo Alto Networks Product Security Assurance team has evaluated the following open source software (OSS) CVEs as they relate to PAN-OS software. While PAN-OS software may include the
CVEs: CVE-2010-1622, CVE-2015-7552, CVE-2018-16840, CVE-2019-7639, CVE-2020-17049, CVE-2020-7774, CVE-2021-0131, CVE-2021-0132, CVE-2021-0133, CVE-2021-0134, CVE-2021-4044, CVE-2021-4160, CVE-2021-41773, CVE-2022-1343, CVE-2022-21449, CVE-2022-2274, CVE-2022-22963, CVE-2022-22965, CVE-2022-24697, CVE-2022-32207, CVE-2022-3358, CVE-2022-3996, CVE-2022-40664, CVE-2022-44792, CVE-2022-44793, CVE-2023-1255, CVE-2023-22809, CVE-2023-23919, CVE-2023-3341, CVE-2023-4236, CVE-2023-4863, CVE-2023-51767
Affected products: PAN-OS
Ubuntu
OpenSSL vulnerabilities
vendor_ubuntu·2022-11-01·CVSS 7.5
CVE-2022-3358 [HIGH] OpenSSL vulnerabilities
Title: OpenSSL vulnerabilities
Summary: Several security issues were fixed in OpenSSL.
It was discovered that OpenSSL incorrectly handled certain X.509 Email
Addresses. If a certificate authority were tricked into signing a
specially-crafted certificate, a remote attacker could possibly use this
issue to cause OpenSSL to crash, resulting in a denial of service. The
default compiler options for affected releases reduce the vulnerability to
a denial of service. (CVE-2022-3602, CVE-2022-3786)
It was discovered that OpenSSL incorrectly handled applications creating
custom ciphers via the legacy EVP_CIPHER_meth_new() function. This issue
could cause certain applications that mishandled values to the function to
possibly end up with a NULL cipher and messages in plaintext.
(CVE-2022-3358)
In
Red Hat
openssl: Using a Custom Cipher with NID_undef may lead to NULL encryption
vendor_redhat·2022-10-11·CVSS 7.5
CVE-2022-3358 [HIGH] CWE-476 openssl: Using a Custom Cipher with NID_undef may lead to NULL encryption
openssl: Using a Custom Cipher with NID_undef may lead to NULL encryption
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_CIP
Debian
CVE-2022-3358: openssl - OpenSSL supports creating a custom cipher via the legacy EVP_CIPHER_meth_new() f...
vendor_debian·2022·CVSS 7.5
CVE-2022-3358 [HIGH] CVE-2022-3358: openssl - OpenSSL supports creating a custom cipher via the legacy EVP_CIPHER_meth_new() f...
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 give
No detection rules found.
https://git.openssl.org/gitweb/?p=openssl.git%3Ba=commitdiff%3Bh=5485c56679d7c49b96e8fc8ca708b0b7e7c03c4bhttps://psirt.global.sonicwall.com/vuln-detail/SNWLID-2022-0023https://security.gentoo.org/glsa/202402-08https://security.netapp.com/advisory/ntap-20221028-0014/https://www.openssl.org/news/secadv/20221011.txthttps://git.openssl.org/gitweb/?p=openssl.git%3Ba=commitdiff%3Bh=5485c56679d7c49b96e8fc8ca708b0b7e7c03c4bhttps://psirt.global.sonicwall.com/vuln-detail/SNWLID-2022-0023https://security.gentoo.org/glsa/202402-08https://security.netapp.com/advisory/ntap-20221028-0014/https://www.openssl.org/news/secadv/20221011.txt
2022-10-11
Published