Improper Verification of Cryptographic Signature (CVE-2024-48948)

[avembankottu]

https://security.snyk.io/vuln/SNYK-JS-ELLIPTIC-8187303

[bora-yuksel-1]

+1 to this, seems like a PR is already open for this issue: #322

[un4ckn0wl3z]

+1

[avembankottu]

any idea when will it get merged ?

[LordOfCinder2000]

+1

[paulmillr]

1. This is not CVE: just a bug.
2. Maintainer is currently focused on other important things, so it's unclear when it would be fixed.
3. Switch to newer package noble-curves instead.

[jcheung-xmatters]

+1
Unfortunately it's not as simple as "switch to another package", as this library is a dependency 4 levels down in my project.

[chadlwilson]

Fixed in 6.6.0 via #326 - you can close this issue now.

[avembankottu]

Snyk complaining that the vuln still exist in 6.6.0 via #326 @chadlwilson

[chadlwilson]

Then you should contact Snyk to ask them to re-assess and update the fixed version. An OSS project with volunteer contributors does not control proprietary security tool databases - there's no point complaining about that here.

[bleichenbacher-daniel]

Sorry for being late here. I can confirm the claim that the vulnerability still exists in version 6.6.0 as claimed by Snyk. (Similarly version 6.6.1 is still vulnerable). Additionally simply switching to another library or a potentially future update of this library may not be enough. The easiest exploit of the vulnerability happens when an attacker has a faulty and correct signature of the same message as in this case typically the private key leaks. Hence a key revocation might be a good idea.

CVE-2024-48948 is somewhat misleading, since it only reports the information known at the time it was issued. Not sure what the best way is to fix this.

The organization to analyze and fix this issue is disappointing. For example I can't find sufficient information about the bn.js issue related to this. E.g. the attack I've analyzed are passive attacks: the attacker just hopes to be lucky and observe faulty signatures. Hence it is quite unclear if additional attacks can be launched with chosen message attacks.

[chadlwilson]

I dont think there was a claim one way or another by Snyk - 3 months ago they just hadn't updated the fix version at the time this issue was created and the fix (reportedly) released. Looks like Snyk have updated since then, for better or worse.

But it seems we cant even rely on people reporting issues on GH to even follow up on the issues they raised to help the maintainers, let alone expect more free time/energy from maintainers.

In any case, I'm not sure how it helps to keep putting messages over the place (#321 , #322 , yet strangely not the actual PR that allegedly has the incomplete fix at #326 )

What are you trying to achieve? If you want the CVE text to be updated, you can go via the CNA/Mitre or whomever raised the CVE?

If you have a PoC that proves the issue still exists, can energy be redirected into PRing a proper fix instead?

[bleichenbacher-daniel]

Chad,

I don't really understand your claim that people are not following up on their claims. I've written some tests that show that the library is buggy and I have been rerunning the same test against new versions. The tests still fail despite claims to the contrary. An example of a failing test has been analyzed in #322 . The results have been reported there.

#321 and #322 are the issues referenced in CVE 2024-48948. So giving updates there certainly makes sense.

What I'm trying to achieve is to make recommendations for applications that use this library. If it takes more than 6 months to fix an issue like this, then I think it is quite obvious that I prefer other libraries.

And it certainly feels like a waste of time having to follow up on issue like this just because someone claims it has been fixed without testing. Hence I'm looking for projects that would streamline the process. js-crev seems somewhat promising, but looks dead. Maybe someone has a better idea.

[chadlwilson]

I don't really understand your claim that people are not following up on their claims.

I don't know what you are talking about here.

You said

I can confirm the claim that the vulnerability still exists in version 6.6.0 as claimed by Snyk

I said

I dont think there was a claim one way or another by Snyk - 3 months ago they just hadn't updated the fix version at the time this issue was created

All I am saying is that we should discount whatever is in Snyk's vulnerability report about whether it is fixed or not, these orgs typically do not go into detail as they are not generally cryptographers, generally they read/assess the public information available including from maintainers of a project, and they do not re-review unless someone (a customer in Snyk's case) asks them to and goes to the effort to supply additional context.

#321 and #322 are the issues referenced in CVE 2024-48948. So giving updates there certainly makes sense.

All I am saying is that I'm also not sure how it helps to put messages across multiple issues/PRs without perhaps consolidating, and/or without suggesting some sort of fix. Perhaps send a friendly chaser on #322 to see if the maintainer has had time to look at it? Maybe they just missed it/forgot?

And it certainly feels like a waste of time having to follow up on issue like this just because someone claims it has been fixed without testing.

Are you referring to me? Or the original maintainer's assertion it had been fixed via #326?

In any case, it may be a waste of time, and I am sure it is very frustrating, but this appears to be largely a single-person project, and complaining it is not fixed likely won't actually get it fixed. I am sure the maintainer thought they had fixed it in #326, and it's reasonable to assume the best isn't it? Maybe best to remember the core of what open source is - free stuff others are providing. They don't owe anything to you, or any of us - even if it leaves us in a bad state with an unmaintained security-sensitive library many of us wouldn't have the expertise to fork-and-maintain ourselves.

Given the original vulnerability ended up disclosed via #322 3 months after no response to a private vuln disclosure attempt, it's not looking so good to rely upon this library.