Statement on NPM Package Vulnerability in v5.0.2-5.1.0 of Copay Bitcoin Wallets
blog.bitpay.com
blog.bitpay.com
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.
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.
NPM has a file called “package-lock.json” which locks all dependencies including dependencies of dependencies and so on.
What it they lock down a version with compromised code in it well before it is discovered?
Locking down does not help if checkins are not scrutinized for malicious code.
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).
- "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.
You have to weigh the risk of going out of business because you didn't deliver value fast enough vs. the risk of having a security incident.
In the Node ecosystem there are SAAS products (https://greenkeeper.io/) that will automatically update your dependencies, run your tests, and merge in the updates (that line change I showed is an example of what it would look like) if the tests pass. That shows you how much thought Node/JS developers put into upgrading their dependencies.
The event-stream update would be done automatically in this instance because the code still worked, although it was compromised.
This hack has nothing to do with the scm but everything with the carelessness of npm.
Or are you suggesting that all code in github should be considered untrusted, but somehow able to be verified by npm?
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?
"@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...
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.
I think many maintainers would have done the same.
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.
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.
If the other dev who injected the backdoor had waited a year or so, pretending to actually maintain the package first, what then?
If you're writing code dealing with sensitive information (say, credit card, cryptocurrency credentials, private information etc...) and you don't even bother to vet your dependencies and when it blows in your face your first reflex is to shift blame on some guy who's giving your source code free on the internet you should really think hard about what you're doing.
Can you imagine that flying in any other industry? "Bridge collapses because company bought crappy steel from some guy off e-bay, but hey he had a trustworthy nickname."
I mean, the injection was finally discovered because of a deprecation warning: https://github.com/remy/nodemon/issues/1442
I wonder how many backdoored node packages there are out there, but judging by how this issue was handled I'd guess probably more than 0.
If there's one positive consequence to this cryptocurrency craze it's that it shines light on our terrible so-called "engineering" practices in the software industry.