GHSA-ppp5-5v6c-4jwp Forge has signature forgery in RSA-PKCS due to ASN.1 extra field
SummaryRSASSA PKCS#1 v1.5 signature verification accepts forged signatures for low public exponent keys (e=3). Attackers can forge signatures by stuffing “garbage” bytes within the ASN structure in order to construct a signature that passes verification, enabling [Bleichenbacher style forgery](https://mailarchive.ietf.org/arch/msg/openpgp/5rnE9ZRN1AokBVj3VqblGlP63QE/). This issue is similar to [CVE-2022-24771](https://github.com/digitalbazaar/forge/security/advisories/GHSA-cfm4-qjh2-4765), but adds bytes in an addition field within the ASN structure, rather than outside of it.Additionally, forge does not validate that signatures include a minimum of 8 bytes of padding as [defined by the specification](https://datatracker.ietf.org/doc/html/rfc2313#section-8), providing attackers additional space to construct Bleichenbacher forgeries.Impacted Deployments**Tested commit:** `8e1d527fe8ec2670499068db783172d4fb9012e5`
**Affected versions:** tested on v1.3.3 (latest release) and recent prior versions.**Configuration assumptions:**Invoke key.verify with defaults (default `scheme` uses RSASSA-PKCS1-v1_5).`_parseAllDigestBytes: true` (default setting).Root CauseIn `lib/rsa.js`, `key.verify(...)`, forge decrypts the signature block, decodes PKCS#1 v1.5 padding (`_decodePkcs1_v1_5`), parses ASN.1, and compares `capture.digest` to the provided digest.Two issues are present with this logic:Strict DER byte-consumption (`_parseAllDigestBytes`) only guarantees all bytes are parsed, not that the parsed structure is the canonical minimal DigestInfo shape expected by RFC 8017 verification semantics. A forged EM with attacker-controlled additional ASN.1 content inside the parsed container can still pass forge verification while OpenSSL rejects it.`_decodePkcs1_v1_5` comments mention that PS < 8 bytes should be rejected, but does not implement this logic.Reproduction StepsUse Node.js (tested with `v24.9.0`) and clone `digitalbazaar/forge` at commit `8e1d527fe8ec2670499068db783172d4fb9012e5`.Place and run the PoC script (`repro_min.js`) with `node repro_min.js` in the same level as the `forge` folder.The script generates a fresh RSA keypair (`4096` bits, `e=3`), creates a normal control signature, then computes a forged candidate using cube-root interval construction.The script verifies both signatures with:forge verify (`_parseAllDigestBytes: true`), andNode/OpenSSL verify (`crypto.verify` with `RSA_PKCS1_PADDING`).Confirm output includes:`control-forge-strict: true``control-node: true``forgery (forge library, strict): true``forgery (node/OpenSSL): false`Proof of Concept**Overview:**Demonstrates a valid control signature and a forged signature in one run.Uses strict forge parsing mode explicitly (`_parseAllDigestBytes: true`, also forge default).Uses Node/OpenSSL as an differential verification baseline.Observed output on tested commit:Suggested PatchEnforce PKCS#1 v1.5 BT=0x01 minimum padding length (`PS >= 8`) in `_decodePkcs1_v1_5` before accepting the block.Update the RSASSA-PKCS1-v1_5 verifier to require canonical DigestInfo structure only (no extra attacker-controlled ASN.1 content beyond expected fields).Here is a Forge-tested patch to resolve the issue, though it should be verified for consumer projects:ResourcesRFC 2313 (PKCS v1.5): https://datatracker.ietf.org/doc/html/rfc2313#section-8This limitation guarantees that the length of the padding string PS is at least eight octets, which is a security condition.RFC 8017: https://www.rfc-editor.org/rfc/rfc8017.html`lib/rsa.js` `key.verify(...)` at lines ~1139-1223.`lib/rsa.js` `_decodePkcs1_v1_5(...)` at lines ~1632-1695.CreditThis vulnerability was discovered as part of a U.C. Berkeley security research project by: Austin Chu, Sohee Kim, and Corban Villa.
CVSS v3.1 score: 7.5