Popular NPM Package Compromised
wow, apparently the popular “event-stream” npm module has been backdoored for months because the maintainer transferred the ownership rights to some unknown person
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.
Holy hell, Node. A package with 2 million downloads a week and the maintainer hands over control to a rando stranger? And now it’s mining cryptocurrency. Wow.
Step 1️⃣ Go through the most popular inactive open source libraries
Step 2️⃣ Reach out to author and ask to help out
Step 3️⃣ Get push access and release a compromised version
Step 4️⃣ Reach 2 million applications within a week
It shows again how much work open source maintenance can be, if your library is successful you have a ton of responsibilities and can cause severe damage
I hope the folks at @github are looking into some procedural ways of mitigating this sort of thing, because it is way too easy to accomplish given the breadth of interconnected libraries out there.
This is not GitHub’s responsiblity, or their fault, but GitHub knows how forked something is, including, I’d imagine, degrees of dependency separation. It could coordinate with npm, brew, et al to classify “community critical” repos. A sort of verified status.
From there you could, among other things, make it harder for an exhausted maintainer to toss the keys to a bad actor. Some sort of two-factor method for ownership transfer. Like a nuclear launch failsafe. Maybe some of this exists, but clearly we need better.
[…]
FWIW, there are some scary details in the comments of that link above that imply the original maintainer still “owned” the repo but lost commit access. This is a terrible scenario akin to identity theft. I don’t know how that’s possible, but it needs to be looked into.
I think blame also goes to an entire culture of developers who blindly import OSS libraries without vetting whether the code is any good or is being actively maintained. I saw this a lot at my last job.
There are basically two camps in that thread.
1) This is the original maintainer’s fault for transferring ownership to someone they didn’t know and trust.
2) Ownership transfer was fine; it’s your job to vet all of the code you run.
Option 2 (vet all dependencies) is obviously impossible. Last I looked, a new create-react-app had around a thousand dependencies, all moving fast and breaking things.
Option 1 (a chain of trust between package authors) seems culturally untenable given the reactions in that thread, including from well-known package authors.
There was an option 3: don’t decompose your application’s dependency graph into thousands of packages. People who argued that position were dismissed as (to paraphrase heavily) old and slow. That ship has sailed, and now we’re here.
Update (2018-11-28): dominictarr:
Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn’t create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I’ve since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I’ve written way better modules than this, the internet just hasn’t fully caught up.
[…]
One time, I was working as a dishwasher in a resturant, and I made the mistake of being too competent, and I got promoted to cook. This was only a 50 cents an hour pay rise, but massively more responsibility. It didn’t really feel worth it. Writing a popular module like this is like that times a million, and the pay rise is zero.
Update (2018-12-03): Carlos Davide (via Hacker News):
Not so much for Tarr, though, who got the crap end of the Internet for handing over the package without properly vetting the stranger. How Tarr would have been able to do so in a way that is 100% safe is not clear to me at this stage, but lets roll for a bit with the assumption that a small amount of extra care on Tarr’s part could have avoided this mess.
This would mean that the original author of any FOSS package or application, by publishing it, would have to accept as fact that any misuse of said software would forever be their responsibility, or at least until that responsibility is, diligently and ceremoniously, transferred to someone else, hot potato style.
You know, like we do in the corporate world.
[…]
Code is the only thing you can trust, and by not reading it, you’ve forfeited the most important benefit provided by this ecosystem: the choice of not having to trust the authors regarding behavior or continuity.
[…]
We may have reached a stage where FOSS doesn’t represent everything it used to anymore, simply because there is too much of it. Too many lines of code, too many competing solutions, too fast a rate of change. We want to keep those security updates coming in straight from upstream, but how are we going to do audits every week on our current constraints?
Update (2018-12-12): The Changelog:
Adam and Jerod talk with Dominic Tarr, creator of event-stream, the IO library that made recent news as the latest malicious package in the npm registry. event-stream was turned malware, designed to target a very specific development environment and harvest account details and private keys from Bitcoin accounts.
They talk through Dominic’s backstory as a prolific contributor to open source, his stance on this package, his work in open source, the sequence of events around the hack, how we can and should handle maintainer-ship of open source infrastructure over the full life-cycle of the code’s usefulness, and what some best practices are for moving forward from this kind of attack.
2 Comments RSS · Twitter
Of course now that this has happened you'll have con artists and the like replicating it. I think Bernhardt is completely correct in his analysis but I don't think open source will change until we've had thousands more cases like this.
I should note I've been expecting this sort of thing for ages - ever since the programmers library market dried up because of open source. There's simply an advantage to having a legal entity behind code. It's not perfect but there is a strong value because there are incentives to keep the code safe. With open source that isn't there and once open source became so diverse yet entwined problems like this became inevitable.
What's shocking isn't that this problem happened. It's that it took so long for it to happen.
> Of course now that this has happened you'll have con artists and the like replicating it.
I think they already knew about this since long ago. This article from januari pretty much predicted it:
https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5
