Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Backdoor in event-stream library dependency

github.com

Post reply on HN
Print view View original

261–270 of 509 posts

Re: Backdoor in event-stream library dependency

#261

Post by devcpp »

the_mitsuhiko wrote: post #245
CoffeeDregs wrote: post #230

A related question: I'm a NodeJS, Python and Java user/developer; can anyone explain why this problem appears more frequently in the npm ecosystem than in Maven, PyPi, etc? Is it the Github-ization of package creation and maintenance? Is it the pervasiveness of left-pad style packages? Is it npm's governance? Is it the community's perspective and culture? Have the malicious just not made it to other repo systems yet?

Lots of tiny dependencies.

Exactly. As a Java dev, I can't imagine creating a dependency for such a tiny thing. I would want a reputable library. My dependency tree can grow pretty big but not nearly as much as my typical node_modules.

Re: Backdoor in event-stream library dependency

#262

Post by wild_preference »

scarejunba wrote: post #178
jameslk wrote: post #152

I see a lucrative business opportunity in alerting users when pwned/vulnerable NPM packages are used in their projects. Maybe something like this exists already?

GitHub does it for Ruby Gems.

They do it for NPM deps too.

Re: Backdoor in event-stream library dependency

#264

Post by gkya »

CoffeeDregs wrote: post #230

A related question: I'm a NodeJS, Python and Java user/developer; can anyone explain why this problem appears more frequently in the npm ecosystem than in Maven, PyPi, etc? Is it the Github-ization of package creation and maintenance? Is it the pervasiveness of left-pad style packages? Is it npm's governance? Is it the community's perspective and culture? Have the malicious just not made it to other repo systems yet?

> Is it the Github-ization of package creation and maintenance? Is it the pervasiveness of left-pad style packages? Is it npm's governance? Is it the community's perspective and culture?

A nasty combination of all of those, probably some more.

I was very excited with Node.js when I first heard about it here on HN years ago. I enjoyed watching Dahl's presentation. But as soon as the crowd that went "it's JS, I can document.getElementsByClassName(...), so I can code servers" flocked in and npm became a thing, that was the end of Node.js as a nice, bright little thing.

I don't want to defend or encourage gatekeeping, but Node.js brought in lots of folk that did not know what they were doing into software development, and they did not stop to learn a thing or two before creating a monstrosity like npm or making things like leftpad and this possible and popular. And there wasn't any seasoned leaders like Python or Perl communities had, so all that happened with no authoritative opposition. If it was Node.lua or Node.pl, the world would've been a different place today for the software development community.

Re: Backdoor in event-stream library dependency

#265

Post by epai »

Tl;dr: event-stream repo was injected with an attack that crawls your dependencies trying to find “copay-dash”. It then attacks it to steal all your bitcoin. The attacker was given maintenance rights to the repo by simply emailing the owner, who gave the rights freely. The owner and npm didn’t do a background check. Because of the MIT license, the owner has no liability/responsibility for his actions.

Re: Backdoor in event-stream library dependency

#266

Post by joshmanders »

gkya wrote: post #220
jhardy54 wrote: post #48

Earlier quoted context omitted.

Especially given that Dominic maintains hundreds of packages[1]. He's a good guy and a great developer, and he's always been supportive of others who want to help out. When working on Scuttlebutt[2] I got some flak for a change I made and he said this[3]: > I argued against this before, but @christianbundy wanted to do it, so I figured okay do it then. Maybe it is annoying for everyone (in which case christian probab…

> Especially given that Dominic maintains hundreds of packages > maintains hundreds of packages > hundreds How can a single human reasonably and responsably do this? This number alone demonstrates how sloppy and inept the Node.js community's practices are.

Node people highly follow the single responsibility principle that is prevalent in Linux. By your logic, Linux is sloppy and inept too.

Re: Backdoor in event-stream library dependency

#267

Post by joshmanders »

gkya wrote: post #264
CoffeeDregs wrote: post #230

A related question: I'm a NodeJS, Python and Java user/developer; can anyone explain why this problem appears more frequently in the npm ecosystem than in Maven, PyPi, etc? Is it the Github-ization of package creation and maintenance? Is it the pervasiveness of left-pad style packages? Is it npm's governance? Is it the community's perspective and culture? Have the malicious just not made it to other repo systems yet?

> Is it the Github-ization of package creation and maintenance? Is it the pervasiveness of left-pad style packages? Is it npm's governance? Is it the community's perspective and culture? A nasty combination of all of those, probably some more. I was very excited with Node.js when I first heard about it here on HN years ago. I enjoyed watching Dahl's presentation. But as soon as the crowd that went "it's JS, I can doc…

> I don't want to defend or encourage gatekeeping

Goes on to defend and encourage gatekeeping.

Re: Backdoor in event-stream library dependency

#268

Post by schneidmaster »

CoffeeDregs wrote: post #230

A related question: I'm a NodeJS, Python and Java user/developer; can anyone explain why this problem appears more frequently in the npm ecosystem than in Maven, PyPi, etc? Is it the Github-ization of package creation and maintenance? Is it the pervasiveness of left-pad style packages? Is it npm's governance? Is it the community's perspective and culture? Have the malicious just not made it to other repo systems yet?

1) Volume -- Javascript is the most popular language right now and it's not really close [1]. Attackers typically focus their efforts on systems that offer the most potential targets.

2) The language -- Javascript has relatively few convenience features in the standard library (at least compared to ruby, which is my point of reference) so more of those features are implemented in userland (and thus imported from npm). I think this is the biggest cause of massive dependency trees -- things like left_pad simply exist natively in many other languages.

3) The ecosystem -- for whatever reason, installing floating package versions was the default for a long time; floating package versions are obviously an order of magnitude more vulnerable to an attacker publishing a malicious update.

Edit: 4) I think it's also probably true that Javascript apps are particularly susceptible to this class of vulnerability, but that doesn't necessarily mean they're less secure overall. Javascript teams tend to move quickly and stay on the cutting edge, so they install lots of packages/updates and are thus vulnerable to malicious updates. Equifax's Java app was compromised for exactly the opposite reason -- they didn't install a security update to Apache Struts for months. That class of vulnerability is far less likely to happen on a fast-moving Javascript app. It's all a tradeoff; the important takeaway is to understand the failure modes for your particular stack and be vigilant against them (which in this case means using a lockfile and doing your best to audit new packages/updates).

[1] https://insights.stackoverflow.com/survey/2018#most-popular-...

Re: Backdoor in event-stream library dependency

#269

Post by yoklov »

wyldfire wrote: post #169
yoklov wrote: post #108

Earlier quoted context omitted.

That doesn't look that far off from what you'll see in generated code, e.g. something like babel could easily output the lines you've pasted. The rest of it is extremely dodgy, of course.

I feared as much would be the case. Even in non-generated code there's perhaps some instances where that code would make sense. However, if you were to audit your dependencies and find a new case of this, you could examine it further to determine whether it passes muster. I suspect code like this is infrequently added to packages.

Eh, again, this kind of thing is common for compiler output, and the use of such compilers is very common.

I think you'd have more luck looking at static strings and warning on any string that has a sufficiently high entropy. Sure, some of them will be hashes for verification, or compressed harmless data, but it it seems like it would be rare enough to be auditable.

Re: Backdoor in event-stream library dependency

#270

Post by AndrewGaspar »

always_good wrote: post #200
AndrewGaspar wrote: post #55

Earlier quoted context omitted.

The reasonable answer is that he should absolutely not have handed over publish capabilities to a completely unknown third-party. This seems obvious to me.

Then let me ask you, how long should have dominic let right9ctrl contribute to the project before trusting him and giving him publish capabilities? With hindsight, we know that right9ctrl is going to publish a backdoor the second he gets rights. How long do you make right9ctrl wait? And does that accomplish what you want? If you think that ownership transfer should exist at all, then the attack vector still exists no…

If I give the maid a key to the house, there's always an attack vector, but that doesn't mean I just go hire some rando off craiglist.

There are a number of factors that could be considered when giving somebody this kind of responsibility, including existing contributions to open source, contributions to the project at hand, and public profile. As far as I can tell, "right9ctrl" had none of these.

Post reply on HN