ghsa-p8c3-7rj8-q963
Vulnerability from github
Impact
Jsrsasign supports ECDSA signature validation which signature value is represented by ASN.1 DER encoding. This vulnerablity may accept a wrong ASN.1 DER encoded ECDSA signature such as:
- wrong multi-byte ASN.1 length of TLV (ex. 0x820045 even though 0x45 is correct)
- prepending zeros with ASN.1 INTEGER value (ex. 0x00000123 even though 0x0123 is correct)
- appending zeros to signature of ASN.1 TLV (ex. 0x3082....1fbc000000 even though 0x3082....1fbc, appending zeros are ignored.)
This vulnerability was fixed by strict ASN.1 DER checking.
Here is an assessment of this vulnerability:
- If you are not use ECDSA signature validation, this vulnerability is not affected.
- Not ASN.1 format signature like just concatenation of R and S value is not affected such as Bitcoin.
- This vulnerability is affected to all ECC curve parameters.
- Risk to accept a forged or crafted message to be signed is low.
- Risk to raise memory corruption is low since jsrsasign uses BigInteger class.
- ECDSA signatures semantically the same to valid one may be accepted as valid. There are many malleable variants.
As discussed here, there is no standards like X9.62 which requires ASN.1 DER. So ASN.1 BER can be applied to ECDSA however most of implementations like OpenSSL do strict ASN.1 DER checking.
Patches
Users using ECDSA signature validation should upgrade to 8.0.19.
Workarounds
Do strict ASN.1 DER checking for ASN.1 encoded ECDSA signature value.
References
https://nvd.nist.gov/vuln/detail/CVE-2020-14966 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14966 https://vuldb.com/?id.157123 https://github.com/kjur/jsrsasign/issues/437 https://kjur.github.io/jsrsasign/api/symbols/KJUR.crypto.ECDSA.html https://kjur.github.io/jsrsasign/api/symbols/ASN1HEX.html#.checkStrictDER https://www.itu.int/rec/T-REC-X.690
{ "affected": [ { "package": { "ecosystem": "npm", "name": "jsrsasign" }, "ranges": [ { "events": [ { "introduced": "4.0.0" }, { "fixed": "8.0.19" } ], "type": "ECOSYSTEM" } ] } ], "aliases": [ "CVE-2020-14966" ], "database_specific": { "cwe_ids": [ "CWE-347" ], "github_reviewed": true, "github_reviewed_at": "2020-06-26T16:54:00Z", "nvd_published_at": "2020-06-22T12:15:00Z", "severity": "HIGH" }, "details": "### Impact\nJsrsasign supports ECDSA signature validation which signature value is represented by ASN.1 DER encoding. This vulnerablity may accept a wrong ASN.1 DER encoded ECDSA signature such as:\n\n- wrong multi-byte ASN.1 length of TLV (ex. 0x820045 even though 0x45 is correct)\n- prepending zeros with ASN.1 INTEGER value (ex. 0x00000123 even though 0x0123 is correct)\n- appending zeros to signature of ASN.1 TLV (ex. 0x3082....1fbc000000 even though 0x3082....1fbc, appending zeros are ignored.)\n\nThis vulnerability was fixed by strict ASN.1 DER checking. \n\nHere is an assessment of this vulnerability:\n\n- If you are not use ECDSA signature validation, this vulnerability is not affected.\n- Not ASN.1 format signature like just concatenation of R and S value is not affected such as Bitcoin.\n- This vulnerability is affected to all ECC curve parameters.\n- Risk to accept a forged or crafted message to be signed is low.\n- Risk to raise memory corruption is low since jsrsasign uses BigInteger class.\n- ECDSA signatures semantically the same to valid one may be accepted as valid. There are many malleable variants.\n\nAs discussed [here](https://crypto.stackexchange.com/questions/24862/ber-or-der-x9-62-for-ecdsa-signature), there is no standards like X9.62 which requires ASN.1 DER. So ASN.1 BER can be applied to ECDSA however most of implementations like OpenSSL do strict ASN.1 DER checking.\n\n### Patches\nUsers using ECDSA signature validation should upgrade to 8.0.19.\n\n### Workarounds\nDo strict ASN.1 DER checking for ASN.1 encoded ECDSA signature value.\n\n### References\nhttps://nvd.nist.gov/vuln/detail/CVE-2020-14966\nhttps://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14966\nhttps://vuldb.com/?id.157123\nhttps://github.com/kjur/jsrsasign/issues/437\nhttps://kjur.github.io/jsrsasign/api/symbols/KJUR.crypto.ECDSA.html\nhttps://kjur.github.io/jsrsasign/api/symbols/ASN1HEX.html#.checkStrictDER\nhttps://www.itu.int/rec/T-REC-X.690\n\n", "id": "GHSA-p8c3-7rj8-q963", "modified": "2023-01-31T01:29:53Z", "published": "2020-06-26T16:54:15Z", "references": [ { "type": "WEB", "url": "https://github.com/kjur/jsrsasign/security/advisories/GHSA-p8c3-7rj8-q963" }, { "type": "ADVISORY", "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14966" }, { "type": "WEB", "url": "https://github.com/kjur/jsrsasign/issues/437" }, { "type": "WEB", "url": "https://github.com/kjur/jsrsasign/commit/6087412d072a57074d3c4c1b40bdde0460d53a7f" }, { "type": "WEB", "url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14966" }, { "type": "PACKAGE", "url": "https://github.com/kjur/jsrsasign" }, { "type": "WEB", "url": "https://github.com/kjur/jsrsasign/releases/tag/8.0.17" }, { "type": "WEB", "url": "https://github.com/kjur/jsrsasign/releases/tag/8.0.18" }, { "type": "WEB", "url": "https://kjur.github.io/jsrsasign" }, { "type": "WEB", "url": "https://kjur.github.io/jsrsasign/api/symbols/ASN1HEX.html#.checkStrictDER" }, { "type": "WEB", "url": "https://kjur.github.io/jsrsasign/api/symbols/KJUR.crypto.ECDSA.html" }, { "type": "WEB", "url": "https://security.netapp.com/advisory/ntap-20200724-0001" }, { "type": "WEB", "url": "https://vuldb.com/?id.157123" }, { "type": "WEB", "url": "https://www.npmjs.com/package/jsrsasign" } ], "schema_version": "1.4.0", "severity": [ { "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N", "type": "CVSS_V3" } ], "summary": "ECDSA signature validation vulnerability by accepting wrong ASN.1 encoding in jsrsasign" }
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.