CVE Tools

CVE-2022-3358

Using a Custom Cipher with NID_undef may lead to NULL encryption

No known exploitation. EPSS puts it in the 88th percentile. A vendor fix is available.

Published Updated Sources: CVE.org, NVD, GitHub, BDU

What to do

The vendor has published a fix. Version details are below where the sources state them.

What it is

From the CVE record

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

In plain language

No plain-language summary for this CVE yet.

Exploitation

Where each signal puts this CVE on the scale from published to confirmed exploited.

EPSS88th
CISA KEV

Not in the catalog. CISA has not confirmed exploitation.

Public exploits

No public exploit or proof of concept found in the sources we track.

EPSS

3.2% chance of exploitation activity in the next 30 days, which ranks it in the 88th percentile of scored CVEs.

Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.

Lifecycle

7 events over 1353 days, from the signal feeds we watch.

  1. OpenVAS check added
  2. EPSS band changemoderate → low
  3. Patch availablerecord updated
  4. Publishedweakness classified, att&ck mapped

Affected products

Technical detail

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Scored 7.5 by NVD.

How it is reached

  • Attack Vector NetworkExploitable remotely over the network without any special conditions
  • Attack Complexity LowNo special conditions — the attack can be reliably reproduced
  • Privileges Required NoneNo authentication required — anyone can exploit this
  • User Interaction NoneNo user interaction needed — fully automated exploitation

Scope

  • Scope UnchangedImpact is limited to the vulnerable component itself

Impact if exploited

  • Confidentiality HighTotal information disclosure — all data in the component is compromised
  • Integrity NoneNo integrity impact
  • Availability NoneNo availability impact

Weaknesses

ATT&CK techniques

Mapped from the weaknesses above (CWE to ATT&CK), not observed in attacks.

Sources

Watch the software you run.

My Stack ranks new CVEs for your products by real-world exploitation, so the next serious one reaches you without reading every advisory.

We'll flag the next CVE, public exploit or patch for OpenSUSE Leap, not every advisory.

We use analytics cookies to see which pages and articles actually help people. Decline and none of them run — the site works the same. What we store