cosmos
impact of elliptic vulnerabilities
For versions of CosmJs before #1628 (0.33.1) and #1272 (0.34.0), what impact do the known vulnerabilities in elliptic have?
- The vulnerability patched in 0.33.1 requires "signing a malformed input." https://github.com/indutny/elliptic/security/advisories/GHSA-vjh7-7g9h-fjfh Were versions pre-0.33.1 vulnerable to malicious RPC servers?
- The vulnerability patched by removing elliptic in 0.34.0 requires signing the same message twice. https://github.com/indutny/elliptic/issues/321 Were any CosmJS users vulnerable, either with honest RPC servers, or malicious ones?
- Is private key revocation recommended?
The majority of CosmJS user do not use CosmJS for key storage, signing or signature verification in production. In fact I am not aware of any wallet or other project using that crypto. This makes this case relatively relaxed.
However, if there are projects who generate private keys, store private keys, sign transactions or verify transactions with CosmJS I'd be interested to learn about them. They might be affected by some of the open issues in elliptic.
Checking https://www.npmjs.com/browse/depended/@cosmjs/proto-signing is mostly useless it turns out. It said there were 972 dependents total, but there's no way to sort them by downloads count, and also the list just stops at the 11th page of results, which is only the first 396 of them.
But @cosmjs/proto-signing DirectSecp256k1HdWallet and SigningStargateClient.connectWithSigner are definitely deployed in the wild with real users. Specifically, Thorchain wallet apps have been using that code. https://github.com/xchainjs/xchainjs-lib/blob/cf87eecb232aa0f8cfec6bd48a43435dca5dbf83/packages/xchain-thorchain/src/clientKeystore.ts#L230
I guess one question is would any kind of malformed input from the first vulnerability be able to slip past basic parsing validation in the API?
But then, for the second vulnerability, there's no such accidental defense possible. You just need to use the same seed phrase and derivation path => the same private key in multiple wallets, or in different versions of the same wallet software. Then getting tricked into re-signing the same transaction produces 2 different signatures. Once with a wallet that produces faulty signatures using elliptic and once with a wallet that produces correct signatures.
The majority of CosmJS user do not use CosmJS for key storage, signing or signature verification in production. In fact I am not aware of any wallet or other project using that crypto
Are there actual numbers to figure out who the majority of users even are? It wasn't even that long ago a user filed an issue about using signAndBroadcast in #1647. How many aren't filing any issues at all?
This really doesn't seem like the kind of thing that can be safely ignored, it needs an advisory reported in https://github.com/cosmos/cosmjs/security that'll show up whenever people run npm audit. And it would make sense to deprecate all older versions on NPM to really warn people:
https://docs.npmjs.com/deprecating-and-undeprecating-packages-or-package-versions#deprecating-a-single-version-of-a-package
npm deprecate '@cosmjs/crypto@<0.34' "This version contains a critical private key disclosure bug [link to GHSA]. Please upgrade"
The deprecation note is a good idea indeed. It's here now: https://www.npmjs.com/package/@cosmjs/crypto/v/0.33.1.
it needs an advisory reported in https://github.com/cosmos/cosmjs/security that'll show up whenever people run npm audit
True, but this is something that belongs in the elliptic repo, right? I don't think it is scalable for bugs in dependencies to be repeated in higher level libraries.