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

431–440 of 509 posts

Re: Backdoor in event-stream library dependency

#431

Post by bmurphy1976 »

AgentME wrote: post #388
faho wrote: post #351

Earlier quoted context omitted.

It's not. Not to that degree. Unix frequently espouses "do one thing", but how much "one thing" is is always open to interpretation. And it's never been quite as small as e.g. left-pad. It's more something like `printf` or `cat`, which do "print a formatted string" and "concatenate files" as their "one thing", respectively. Let me reiterate: The problem isn't "single responsibility", the problem is "single responsibi…

`cat` without any options support is possibly simpler than left-pad. I think the big difference is that very few people set their systems to trust and receive updates of `cat` directly from the developers of `cat` (and same for all the other standard tiny utilities). Instead, they rely on a Linux distribution to vet the developers' code and to regularly pull in updates. Maybe there's room for a similar model of distr…

Do you really think cat is as simple as left-pad?

https://github.com/freebsd/freebsd/blob/master/bin/cat/cat.c

Also, cat is kind of an important primitive for building a functional system that uses files as one of its core abstractions. It makes total sense that it would (a) exist and (b) be well maintained by an authoritative and reliable source.

Left pad it is not.

Re: Backdoor in event-stream library dependency

#432

Post by robot2051 »

robot2051 wrote: post #429

Not sure how useful this would be to anyone but i built this tool last year to learn about Go and highlight issues with dependencies. This tool tries to enumerate dependencies of the project and highlight concerning facts for each dependency such as the size of collaborator, the age of the repository or if it has not been updated for more than 6 months, etc.. The tool currently supports go-dep, npm, pip, ruby-gem but…

PS: if you fork the project, it will have big security warning for dependencies, that is because i have a couple of test dependency files for pip,nodejs,rubygem for testing the crawler job.

Re: Backdoor in event-stream library dependency

#433

Post by always_good »

gyrgtyn wrote: post #341
always_good wrote: post #93

There are a few issues with NPM that make this kind of thing especially easy/lucrative: - An ecosystem of massive amounts of transitive dependencies increases the number of people you need to trust. If I wanted to attack a project that used NPM, their package.json dependencies would be a really good place to start. Find the least popular transitive dep they use and email the owner to see if you can be a contributor (…

I don't see how the same thing couldn't happen with an elm package? The attacker can commit to the github repo.

Be specific: what exactly would you do in Elm to pwn someone? It would be a much more limited and a much more visible attack.

NPM modules don't even have source code on display. Someone has to download and check the tarball before npm install.

Also, Elm packages are qualified by a github username so there isn't an ecosystem of ownership transfer. No juicy name squatting. People just fork.

Finally, don't forget that my point is "there are a few issues with NPM that make this kind of thing especially easy/lucrative". That's a far cry from "everything else is bullet-proof" but it's tempting to argue with me as if I'm saying that.

Re: Backdoor in event-stream library dependency

#434

Post by altfredd »

devman0 wrote: post #307
perfunctory wrote: post #96

Earlier quoted context omitted.

I don't even see any moral issues here. Is there any reason to believe the original author acted in bad faith? If you sell your used car and it gets used to rob a bank, did you act immorally?

When you sell your car there is generally a title transfer. A process which lets everyone know that the car is no longer yours. I think the largest gripe here is that the original maintainer let the new, unknown maintainer commit to his repo and publish under the already established package name instead of making him fork it and publish as a new package.

There is nothing wrong with publishing rewritten package with same name under full supervision of original developer. Transferring control generally implies full trust, and Dominic haven't established any trust with new developer. He didn't even ask them for their real name!

Re: Backdoor in event-stream library dependency

#435

Post by bandrami »

MrStonedOne wrote: post #353
bandrami wrote: post #311

So, I'm not a javascript person. I don't know the ecosystem that well. I'm not really even a programmer except at gunpoint, just a sysadmin. But even 5 years ago I remember thinking "400 dependencies for a project is just WAY too many" and imagining something like this. And now I see some of the big frameworks require literally thousands of packages. Is there something about Javascript that necessitates this kind of…

In the web, any dependencies have to be sent to the client as well, so making them small and having the build chain handle grouping them all up in one minified file is suppose to make things quicker for clients. also languages like python require an affirmed compile time resolved call to the classes so it can more easily know what code is not used or not going to ever be used. Javascripts string based introspection a…

People surely aren't evaluating strings in production code, are they? The LISPer in me just died a little.

Re: Backdoor in event-stream library dependency

#436

Post by bmurphy1976 »

jrochkind1 wrote: post #375
ryandrake wrote: post #290

Earlier quoted context omitted.

Interesting, thanks for the explanation. I was not familiar with the npm ecosystem. If the ecosystem has a cultural norm of "blindly" updating dependencies regularly, that could be the root problem. If you're going to live on the bleeding edge, rolling the dice over and over, you're going to have a bad roll once in a while. Your world seems more sane, and I (also not in node, JavaScript, npm etc.) generally follow th…

You misunderstood me. I don't work much with npm. I work mostly with ruby, using bundler for dependency management. And i update my dependencies to new patch releases _all the time_ without reviewing the releases individually. I think most other ruby devs do too. My understanding of the intention of "semantic versioning" is to _allow_ you to do that. My projects have dozens if not hundreds of dependencies -- don't fo…

Not just that, but the longer you wait the more you diverge from mainline. The more you diverge, the more painful re-integration will be.

By updating all the time you can address bugs and changes as simple fixes here and there. Wait too long and you run the risk of having a really painful merge/update cycle, most likely happening under duress because now you have to update because of some bug fix or security issue.

The more dependencies you have, the more critical it is to stay up-to-date, and thus this directly leads to all the craziness with NPM based projects whenever something goes wrong.

Re: Backdoor in event-stream library dependency

#437

Post by sdbrown »

always_good wrote: post #93

There are a few issues with NPM that make this kind of thing especially easy/lucrative: - An ecosystem of massive amounts of transitive dependencies increases the number of people you need to trust. If I wanted to attack a project that used NPM, their package.json dependencies would be a really good place to start. Find the least popular transitive dep they use and email the owner to see if you can be a contributor (…

> People ITT blaming the OP don't understand this attack always works on a long enough timescale.

I'm a little dismayed by the great number of comments I had to read before someone pointed this out...

Re: Backdoor in event-stream library dependency

#438

Post by danso »

tboyd47 wrote: post #383

I don't think most people in HN are seeing the real story here. This is not another harmless stunt like left-pad to make us all wag our fingers at the Node community. This is a coordinated, targeted attack on a popular Bitcoin wallet software to steal private keys using a popular open source library and NPM as an attack vector. This is potentially the biggest Bitcoin heist since MTGox and the biggest news in Bitcoin…

Most people on HN may not be Bitcoin investors. More HN people are probably programmers who depend on open source.

Re: Backdoor in event-stream library dependency

#439

Post by marco1 »

We may need permissions for our dependencies (cf. Android apps). Ryan Dahl already did this with Deno, specifically because he saw weaknesses in Node: network, environment variables, file system, sub-processes.

We may need reproducible builds and reproducible minification. If we want developers to audit their own dependencies, in case we deem that practical, packages cannot ship their own minified sources. Auditing the non-minified source is hard enough.

We may need (for-profit) organizations that audit packages and award their official seal which you can trust before you add or update a dependency.

We may need better standard libraries and fewer micro-packages.

Re: Backdoor in event-stream library dependency

#440

Post by infinite8s »

jrochkind1 wrote: post #375
ryandrake wrote: post #290

Earlier quoted context omitted.

Interesting, thanks for the explanation. I was not familiar with the npm ecosystem. If the ecosystem has a cultural norm of "blindly" updating dependencies regularly, that could be the root problem. If you're going to live on the bleeding edge, rolling the dice over and over, you're going to have a bad roll once in a while. Your world seems more sane, and I (also not in node, JavaScript, npm etc.) generally follow th…

You misunderstood me. I don't work much with npm. I work mostly with ruby, using bundler for dependency management. And i update my dependencies to new patch releases _all the time_ without reviewing the releases individually. I think most other ruby devs do too. My understanding of the intention of "semantic versioning" is to _allow_ you to do that. My projects have dozens if not hundreds of dependencies -- don't fo…

And therefore you are ultimately responsible if any of those dependencies leaks your users data or compromises them. Just because that's how you choose to work doesn't absolve you of those responsibilities.
Post reply on HN