Issue summary: Encrypting a CMS message to an EC certificate whose group order
is 1 may cause CMS_encrypt() or CMS_encrypt_ex() to loop indefinitely.
Impact summary: An attacker able to supply the recipient certificate to an
application performing CMS encryption can cause that application to loop
indefinitely, consuming CPU and resulting in Denial of Service.
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Description: CMS_encrypt() and CMS_encrypt_ex() encrypt a message to one or
more recipient certificates and, for an EC recipient, generate an ephemeral
key in the recipient's group. If the certificate declares a group order of 1,
random scalar generation can only produce zero. The key generation routine
then retries without limit while waiting for a nonzero private scalar, so the
call never returns.
The OpenSSL TLS and QUIC implementations do not use this path. An application
is exposed only if it calls CMS_encrypt() or CMS_encrypt_ex() with a recipient
certificate whose EC parameters are attacker-controlled. Certificates with
normal EC group orders do not trigger the loop.
OpenSSL 4.0 and later reject unknown explicit EC groups in default builds.
These versions are affected only when configured with the
enable-ec_explicit_curves option.
The result is a hang that consumes a CPU core until the process is
interrupted, a Denial of Service. The severity is Low because the attacker
must supply the recipient certificate and the application must choose to
encrypt to it; ordinary CMS encryption to trusted recipients is unaffected.
The fix makes EC key generation fail when the group has no valid nonzero
private scalar, instead of retrying indefinitely.
FIPS impact: no
The FIPS modules in 4.1, 4.0, 3.5 and 3.0 are not affected. The FIPS provider
does not support arbitrary explicit EC domain parameters, so an order-1 group
is rejected during key import before the vulnerable key generation path is
reached.
What the EG score is made of (scorer v4.0: the three questions the 0–10 score mixes, published apart · methodology)
- EG Severity
- Not assessed: no CVSS publishedA missing CVSS is not a severity of zero.
- EG Likelihood
- 0.1% within 30 daysSource: FIRST EPSS. FIRST's exploitation probability, not an EchelonGraph model.
- Confirmed exploitation
- None on record (CISA KEV, EG-KEV Tier 1)Reported apart from the likelihood: an observed fact, not a probability.
- EG Priority
- No SSVC decision: EchelonGraph has not assessed this CVECISA BOD 26-04: 14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.No released fix is confirmed on this page, but CISA's timeline does not wait for a fix's release: it starts when an agency identifies the flaw on an asset and updates the CDM Agency and Federal Dashboard, and the directive counts patching, decommissioning the system or another action as remediation. Until a fixed release is applied, mitigate as this page's verdict says. In the directive's words, “Fix on system upgrade” means that, “unless conditions change”, the vulnerability “should be remediated the next time the vulnerable asset receives a scheduled major upgrade or rebuild”: its timelines are “dynamic as facts change”, and a KEV listing shortens them.Each input and its source, and whom BOD 26-04 binds: the BOD 26-04 block below.
BOD 26-04 (CISA's remediation timeline, Table 1)14 days if the affected system is publicly exposed; Fix on system upgrade if it is not.
No released fix is confirmed on this page, but CISA's timeline does not wait for a fix's release: it starts when an agency identifies the flaw on an asset and updates the CDM Agency and Federal Dashboard, and the directive counts patching, decommissioning the system or another action as remediation. Until a fixed release is applied, mitigate as this page's verdict says. In the directive's words, “Fix on system upgrade” means that, “unless conditions change”, the vulnerability “should be remediated the next time the vulnerable asset receives a scheduled major upgrade or rebuild”: its timelines are “dynamic as facts change”, and a KEV listing shortens them.
The score's inputs: In CISA KEV no (CISA's KEV catalog) · Automatable no (CISA's BOD 26-04 default) · Technical impact total (CISA's BOD 26-04 default). Where an input reads “CISA's BOD 26-04 default”, no one has published it for this CVE, and CISA's implementation guidance says: “If “Automatable” and “Technical Impact” information items about a CVE ID are not available and the CVE ID is not in the KEV Catalog, CISA will treat its values as “no” and “total,” respectively, until CISA or a third party provides metadata about the CVE ID. CISA will always provide the Vulnrichment data for a CVE ID listed in the KEV Catalog.” Whether your system is publicly exposed is yours to answer. BOD 26-04 binds US Federal Civilian Executive Branch agencies; for anyone else it is CISA's published timeline, a reference rather than an obligation. The directive · how EchelonGraph applies it