GHSA-9c8r-76f3-m426: Signature::from_der reads a signature with bytes after it, a wrong sequence length or an unneeded zero as the signature
Signature::fromder read a DER-encoded ECDSA signature leniently. It read as the signature: the signature followed by other bytes; a sequence length shorter than its contents, or longer with bytes after them (a length byte with its high bit set among them); and an R or S preceded by a zero byte it did not need. It read a lone-zero R or S as zero.
messages::verify, compat::bsm::verifymessageder, auth::Certificate::verify, auth::VerifiableCertificate::verify, wallet::ProtoWallet::verifysignature and kvstore::KVStoreInterpreter::verifysignature read through it, and each verified such a form of a valid signature. Given one signature a key holder made, anyone could produce other byte strings that verify as that signature over the same data. No form verifies over other data: an application that acts on the verdict alone is not affected; one that compares, hashes or stores a signature's bytes is.
0.8.6 refuses each form as Error::InvalidSignature. A signature's bytes are still not unique after the patch: the same signature with S replaced by n - S verifies, so an application that keys on the bytes also requires Signature::islows().
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rust/bsv-rsto a version that resolves this vulnerability.Fixed in 0.8.6 - Upgrade
Upgrade
rust/bsv-rsto a version that resolves this vulnerability.Fixed in 0.9.0-beta.7.0 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 0.8.6 - Compensating control
Require signatures to use low-S form by checking Signature::is_low_s(), because replacing S with n - S can otherwise produce another valid signature over the same data.
Event History
Frequently Asked Questions
Which applications are actually at risk from this issue?
Applications that only use signature verification as a yes/no verdict are not affected. Risk applies when an application compares, hashes, stores, or otherwise treats the raw signature bytes as a unique identifier or value.
What does an attacker need to exploit it?
An attacker needs a valid signature over the same data, such as one produced by the key holder. They can then create alternate byte encodings that verify as that original signature, but cannot make those encodings verify for different data.
Which verification paths accepted these alternate encodings?
The affected parsing behavior was reached through messages::verify, compat::bsm::verify_message_der, auth::Certificate::verify, auth::VerifiableCertificate::verify, wallet::ProtoWallet::verify_signature, and kvstore::KVStoreInterpreter::verify_signature.
What version changes the DER parsing behavior?
Version 0.8.6 rejects the described malformed or non-canonical DER forms with Error::InvalidSignature. It rejects signatures with trailing bytes, inconsistent sequence lengths, unnecessary leading zeroes in R or S, and lone-zero R or S values.
Is upgrading sufficient when signature bytes are used as identifiers?
No. Even after the parsing fix, ECDSA signatures are not unique because replacing S with n - S can produce another valid signature. Applications that key on signature bytes also need to enforce Signature::is_low_s().