ghsa-pwfw-mgfj-7g3g
Vulnerability from github
8.7 (High) - CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
possible DoS in signature verification and signature malleability
Impact
Code using VerifyingKey.verify()
and VerifyingKey.verify_digest()
may receive exceptions other than the documented BadSignatureError
when signatures are malformed. If those other exceptions are not caught, they may lead to program termination and thus Denial of Service
Code using VerifyingKey.verify()
and VerifyingKey.verify_digest()
with sigdecode
option using ecdsa.util.sigdecode_der
will accept signatures even if they are not properly formatted DER. This makes the signatures malleable. It impacts only applications that later sign the signatures or verify signatures of signatures, e.g. Bitcoin.
All versions between 0.5 and 0.13.2 (inclusive) are thought to be vulnerable. Code before 0.5 may be vulnerable but didn't receive extended analysis to rule this issue out.
Patches
The patches have been merged to master
branch in https://github.com/warner/python-ecdsa/pull/115.
The backported patches for a release in the 0.13 branch are in https://github.com/warner/python-ecdsa/pull/124
They are part of the 0.13.3 release.
There are no plans to backport them to earlier releases.
Workarounds
It may be possible to prevent the Denial of Service by catching also UnexpectedDER
, IndexError
and AssertionError
exceptions. That list hasn't been verified to be complete though. If those exceptions are raised, the signature verification process should consider the signature to be invalid.
To remediate signature malleability and the Denial of Service vulnerability, it may be possible to first verify that the signature is properly DER formatted ECDSA-Sig-Value, as defined in RFC3279, before passing it to verify()
or verify_digest()
methods. If the signature is determined to not follow the DER or encode a different structure, the signature verification process should consider the signature to be invalid.
References
https://en.bitcoinwiki.org/wiki/Transaction_Malleability
For more information
If you have any questions or comments about this advisory please open an issue in python-ecdsa project.
{ "affected": [ { "package": { "ecosystem": "PyPI", "name": "ecdsa" }, "ranges": [ { "events": [ { "introduced": "0" }, { "fixed": "0.13.3" } ], "type": "ECOSYSTEM" } ] } ], "aliases": [ "CVE-2019-14853" ], "database_specific": { "cwe_ids": [ "CWE-391", "CWE-755" ], "github_reviewed": true, "github_reviewed_at": "2020-06-16T20:41:53Z", "nvd_published_at": "2019-11-26T13:15:00Z", "severity": "HIGH" }, "details": "## possible DoS in signature verification and signature malleability \n\n### Impact\nCode using `VerifyingKey.verify()` and `VerifyingKey.verify_digest()` may receive exceptions other than the documented `BadSignatureError` when signatures are malformed. If those other exceptions are not caught, they may lead to program termination and thus Denial of Service\n\nCode using `VerifyingKey.verify()` and `VerifyingKey.verify_digest()` with `sigdecode` option using `ecdsa.util.sigdecode_der` will accept signatures even if they are not properly formatted DER. This makes the signatures malleable. It impacts only applications that later sign the signatures or verify signatures of signatures, e.g. Bitcoin.\n\nAll versions between 0.5 and 0.13.2 (inclusive) are thought to be vulnerable. Code before 0.5 may be vulnerable but didn\u0027t receive extended analysis to rule this issue out.\n\n### Patches\nThe patches have been merged to `master` branch in https://github.com/warner/python-ecdsa/pull/115.\nThe backported patches for a release in the 0.13 branch are in https://github.com/warner/python-ecdsa/pull/124\n\nThey are part of the 0.13.3 release.\n\nThere are no plans to backport them to earlier releases.\n\n### Workarounds\nIt may be possible to prevent the Denial of Service by catching also `UnexpectedDER`, `IndexError` and `AssertionError` exceptions. That list hasn\u0027t been verified to be complete though. If those exceptions are raised, the signature verification process should consider the signature to be invalid.\n\nTo remediate signature malleability and the Denial of Service vulnerability, it may be possible to first verify that the signature is properly DER formatted ECDSA-Sig-Value, as defined in [RFC3279](https://tools.ietf.org/html/rfc3279), before passing it to `verify()` or `verify_digest()` methods. If the signature is determined to not follow the DER or encode a different structure, the signature verification process should consider the signature to be invalid.\n\n### References\nhttps://en.bitcoinwiki.org/wiki/Transaction_Malleability\n\n### For more information\nIf you have any questions or comments about this advisory please open an issue in [python-ecdsa](https://github.com/warner/python-ecdsa/issues) project.\n", "id": "GHSA-pwfw-mgfj-7g3g", "modified": "2024-09-20T16:47:14Z", "published": "2019-10-08T16:30:17Z", "references": [ { "type": "WEB", "url": "https://github.com/warner/python-ecdsa/security/advisories/GHSA-pwfw-mgfj-7g3g" }, { "type": "ADVISORY", "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14853" }, { "type": "WEB", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-14853" }, { "type": "WEB", "url": "https://github.com/pypa/advisory-database/tree/main/vulns/ecdsa/PYSEC-2019-177.yaml" }, { "type": "PACKAGE", "url": "https://github.com/warner/python-ecdsa" }, { "type": "WEB", "url": "https://github.com/warner/python-ecdsa/releases/tag/python-ecdsa-0.13.3" }, { "type": "WEB", "url": "https://seclists.org/bugtraq/2019/Dec/33" }, { "type": "WEB", "url": "https://www.debian.org/security/2019/dsa-4588" } ], "schema_version": "1.4.0", "severity": [ { "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H", "type": "CVSS_V3" }, { "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N", "type": "CVSS_V4" } ], "summary": "ecdsa Denial of Service vulnerability in signature verification and signature malleability" }
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.