
Statement on NPM Package Vulnerability in v5.0.2-5.1.0 of Copay Bitcoin Wallets - wslh
https://blog.bitpay.com/npm-package-vulnerability-copay/
======
hn_throwaway_99
The event-stream debacle shows to me how crazy it is that lessons we've known
for literally decades seemed to need to be relearned by the Node community
every couple months (and I say this as someone who is primarily a Node
developer now).

Back in the early 00s I worked on a software build system (Java) that had to
be able to guarantee reproducibility of past versions of builds for code
escrow purposes, and to do that it needed to be able to run builds without a
live internet connection to ensure we didn't have unintended external
dependencies.

The fact that bitpay didn't lock down their version numbers of dependencies,
and are thus at the whim of whatever changes upstream of them are gleefully
picked up, is crazy, _especially_ for a crypto wallet.

~~~
nepeckman
> The fact that bitpay didn't lock down their version numbers of dependencies,
> and are thus at the whim of whatever changes upstream of them are gleefully
> picked up, is crazy, especially for a crypto wallet.

Would that have helped though? This dependency was several layers down, not a
direct dependency of copay. I'm under the impression that even if bitpay
locked their direct dependency, if that dependency auto updates _its_
dependencies, the result is the same.

~~~
javagram
That’s not correct anymore.

NPM has a file called “package-lock.json” which locks all dependencies
including dependencies of dependencies and so on.

------
dboreham
One thing I wonder about when I see this is:

Back in the day the source code control systems I used (primarily CVS and
Subversion but also others) would send a commit/checkin email that contained
the _entire_ set of diffs.

As a development lead and manager I made it part of my daily routine to _read_
the checkin emails. Of course I couldn't read every last line of code, but I
could certainly spot common mistakes such as checking in extra unrelated files
inadvertently; changing tabbing/formatting in code that shouldn't have
changed; and often I'd spot bugs in passing. This wasn't the formal code
review process, but it kept me up to date on what was going into the repo and
it allowed me to catch some basic and obvious errors.

Now, back to the future and GitHub and siblings don't do this. I suspect the
reason is security : the desire to not have source code floating around in
potentially insecure mailboxes.

However, for an OSS project the security concern is moot.

Reading this history of this attack I feel that had someone been reading
commit emails that contained the actual code changed/added, it would have been
easy to detect. As it is, the typical GitHub commit notification email tells
you almost nothing. You have to click through a link to see the changes (which
I'm guessing nobody did in this case).

~~~
atom_arranger
The issue is that the dependency change will show up in the repo as:

\- "event-stream": "1.8.4"

\+ "event-stream": "1.8.5"

Looks completely innocuous, a patch version bump, but it can technically be a
completely different package, it may not even have any relation to any open
sourced code, people can push anything to npm.

People don't check in their dependencies. event-stream is hosted on npm and
downloaded by people who download packages depending on it automatically.
Given this situation there is no diff of it to view.

~~~
mifreewil
yeah - thinking it'd be helpful for npm to have a diff command to check source
changes when doing upgrades.

~~~
btown
Unfortunately, this is made difficult to "bootstrap" due to npm not
supporting/promoting repeatable builds - so you'd just see a diff of minified
messes with no ability to track back to source code changes. You'd want to do
this alongside a rollout of a larger ecosystem around cryptographically secure
repeatable build tracking, which would take time and require "drag-along" of
the entire ecosystem of abandoned packages.

~~~
mifreewil
Very few packages actually contain minified sources - it's not really needed
with modern build tools. I think it was an exception in this case, and that by
itself could be suspicious. Current version of npm now contains a package-
lock.json file which is made to make builds pretty close to deterministic. It
contains the entire dependency tree of dependency names, versions, and hashes.
I say pretty close because it's still possible to break "npm install" by
unpublishing a package.

------
ballenf
As pointed out by others, the attack vector relied on minified code
distributed by NPM being independent from the repository code.

Should we move to having production releases do their own minification
locally? Or, as others have suggested, use tools to parse source and minified
code to identify differences?

~~~
mifreewil
With modern build tools like browserify, webpack, rollup, etc. does it really
make sense to still have non-apps do minification?

------
dboreham
The underlying story is here : [https://github.com/dominictarr/event-
stream/issues/116](https://github.com/dominictarr/event-stream/issues/116)

~~~
malikolivier
Below is the scariest part in this story:

"@dominictarr Why was @right9ctrl given access to this repo?"

Response: "he emailed me and said he wanted to maintain the module, so I gave
it to him. I don't get any thing from maintaining this module, and I don't
even use it anymore, and havn't for years. note: I no longer have publish
rights to this module on npm."

[https://github.com/dominictarr/event-
stream/issues/116#issue...](https://github.com/dominictarr/event-
stream/issues/116#issuecomment-440927400)

~~~
AdmiralAsshat
The same thing happened to gorhill and uBlock/uBlock Origin.

The takeaway seems to be that you should do a background check on anyone
asking to become maintainer of your software.

With that said, this thing seems to have blown up because many large companies
(Microsoft included) appear to use or depend upon this package. If none of
these companies can lend 15 minutes of their engineers' time to help maintain
the free software that they leverage, I can certainly understand the author's
desire to let the module's maintenance become someone else's problem.

~~~
malikolivier
Indeed, the author of this package is not at fault here. It is the
responsibility of the users depending on this package to check in all their
dependencies and ensure to have reproducible builds.

I think many maintainers would have done the same.

~~~
czechdeveloper
That is just not realistic for most people. Maybe big corps can make that, but
even basic things seems to download hundreds of megabytes of dependencies and
I could just read for months before I would even start to develop.

I for sure miss old times when I got .Net framework, maybe some library from 1
or 2 3rd party vendors and I had all I needed for development.

~~~
simias
If you're developing something dealing with sensitive info (like, say,
something processing cryptocurrencies) and you can't audit your codebase then
you shouldn't be doing it in the first place frankly.

Of course in this case this is made worse by the fact that Javascript is so
under-featured by default that you have to pull a ridiculous amount of
dependencies to do anything which makes it a lot harder to audit everything.
Besides since the language is so dynamic it's easy to write a very small, very
powerful "shellcode" that can hook itself up anywhere in the software stack.

------
nubb
In today's world where folks are working hard on stealing crypto, I can't
believe anyone would trust a software wallet. If you're blowing cash on
crypto, the least a person can do is blow a little more on a hardware wallet
or keep it on an exchange.

~~~
Phlarp
We've really come full circle if the prevailing wisdom going into 2019 is to
store coins in an exchange wallet!

~~~
dantillberg
Crypto exchanges have grown a little bit less shady over the past few years.
(some, certainly not all!)

------
xwvvvvwx
This should be on their frontpage: [https://copay.io/](https://copay.io/)

