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

381–390 of 509 posts

Re: Backdoor in event-stream library dependency

#381

Post by raesene9 »

jakelazaroff wrote: post #370
raesene9 wrote: post #273

Earlier quoted context omitted.

oh sure the criminal who put the backdoor in place, no-one's arguing his/her liability. But the point that I was referring to is any suggestion that the repo. owner who handed it over could bear any liability for doing so, I'd suggest that's not probable/practicable.

I don't see how the text of the MIT license can be construed to indemnify a negligent developer but not a malicious one.

Well, let me put it to you this way. If a malware author installs a piece of software on your machine and it steals bitcoins from your machine, do you think they'd be able to argue to a judge that it was all OK 'cause of the software license...

Put it this way, I would not suggest relying on that defence in court.

Re: Backdoor in event-stream library dependency

#382

Post by WorldMaker »

dvlsg wrote: post #225
ummonk wrote: post #212

Earlier quoted context omitted.

As far as I know, you can pin your versions (something I always recommend), but those packages can always pull in other dependencies with version bumps. And NPM in particular encourages a massive plethora of micropackages, so the dependency tree gets extremely large.

Do they? I'm not 100 percent sure about the npm package lock (because I don't typically use it), but I'm fairly sure that yarn's lockfile will lock the full dependency tree, including the dependencies of your dependencies. I believe npm's package lock will as well, but I'd have to double check that.

npm's package lock will lockfile the whole dependency tree, but there are easily overlooked differences between `npm install` and `npm ci` on respecting locked dependencies for things like semver-patch level changes.

`npm ci` is so new a lot of projects aren't using it and are still using `npm install` everywhere. (To be fair, evaluating if most of my projects should switch to `npm ci` in more places is still on my own personal devops backlog. This thread has reminded me to bump priority on that.)

Re: Backdoor in event-stream library dependency

#383

Post by tboyd47 »

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 all year. The last time BitPay got scammed they lost 5,000 BTC and that was back in 2015. I wouldn't be surprised if this is causing the current mass sell-off. Does anyone know how to find real-time transaction volume stats broken down by client, country, etc.?

Re: Backdoor in event-stream library dependency

#384

Post by brobdingnagians »

codetrotter wrote: post #159
programmarchy wrote: post #123

Earlier quoted context omitted.

Dominic is wrong. If there's no authority, then there's nobody taking responsibility. This is a perfect example of how lack of organizational structure simply does not work in the real world. Dominic's other projects like scuttlebutt are likely doomed to fail as well because of his wrongheaded views about organization. For a successful counter-example, one can look at the well-structured, hierarchical organization be…

> other projects like scuttlebutt are likely doomed to fail as well because of his wrongheaded views about organization. Define failure. I don’t know Dominic and I haven’t looked into the Scuttlebutt project beyond being aware of its existence and what it is, but... He talks about creating a community where anyone is welcome to contribute. It is perfectly fine for an open source project to have the development proces…

A security hole and backdoor is always a failure in a software product. Having someone else control your system is just about the worst you can get. It has nothing to do with relative definitions because it always degrades every other objective the project could or does have. If a model of leadership leads naturally and often to security holes, it is time to reconsider the model. If it is a common library, then it is even worse. Open source that is used widely is _even_ more important to protect because the impact can be so much greater.

Re: Backdoor in event-stream library dependency

#385

Post by black-tea »

slg wrote: post #7

I really have a hard time putting as much blame on the author as the people in that Github thread are doing. Maybe they could have handled this specific issue a little better, but the underlying problem is just one of the flaws in the open source community that everyone has to accept. Maintaining a project is a lot of work (even just having your name attached to a dead project involves work) and the benefit from doin…

There is a very strong sense of entitlement in that thread.

Re: Backdoor in event-stream library dependency

#386

Post by nneonneo »

jonknee wrote: post #165
floatingatoll wrote: post #14

Unpinned dependencies are harmful. If you aren’t reviewing the diffs of your dependencies when you update them, you’re trusting random strangers on the Internet to run code on your systems. Espionage often spans multi-year timelines of preparation and trust building. No lesser solution will ever be sufficient to protect you. Either read the diffs, or pay someone like RedHat to do so and hope that you can trust them.

> you’re trusting random strangers on the Internet to run code on your systems I mean that's pretty much how the world works. Even running Linux is trusting random strangers on the internet. Most of the time it works pretty well, but obviously it's not perfect. Even the largest companies in the world get caught with security issues from open source packages (remember Heartbleed?).

When I visit a random website, it is very hard for that website to compromise my computer or my private data. The only really viable way is a zero-day in my browser, or deception (e.g. phishing, malicious download).

When I install an app on my iPhone, it is very very hard for that app to compromise my phone or my private data.

In both of these cases, I can download and run almost any code, and be fairly confident that it won't significantly harm me. Why? Because they're extremely locked down and sandboxed with a high degree of isolation. On the other hand, if I install random software on my desktop computer, or random packages off NPM, I don't have such safety any more.

The prevalence of app stores and the Web itself speaks to the fact that it _is_ possible to trust random strangers without opening yourself up to a big security risk.

Re: Backdoor in event-stream library dependency

#387

Post by zawerf »

Anyone know how this was found and whether that process can be automated? There are likely a lot more packages that are infected with the same technique.

I looked at the linked commits: https://github.com/dominictarr/event-stream/commits/master

and it looks so surprisingly normal.

I am pretty sure I wouldn't have caught it even if I was code reviewing it.

Did someone heroically rerun every package's build process to see if the minified output was tampered with?

Re: Backdoor in event-stream library dependency

#388

Post by AgentME »

faho wrote: post #351
joshmanders wrote: post #266

Earlier quoted context omitted.

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

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 distributions vetting code in the npm ecosystem.

Re: Backdoor in event-stream library dependency

#389

Post by baby »

StavrosK wrote: post #293
samirm wrote: post #251

Earlier quoted context omitted.

Why would the average joe trust something like this? Your FAQ says each maintainer is vetted and handpicked, but nothing about criteria or how they're picked. Do you mind explaining this vetting process a little more? How can we be sure that something like this flatmap thing doesn't happen on codeshelter?

Sure! They're either people I know personally and trust (and hopefully people will trust me to do this transitively) or they are people who are already authors of popular libraries and have shown they are experienced in maintaining OSS projects and trustworthy (since they're already pushing code to people's machines). Trust is definitely an issue here, and trust is something you build, so I hope we'll be able to buil…

to quote linus: if you don't do security with a network of people you trust, you're doing it wrong.

Re: Backdoor in event-stream library dependency

#390

Post by madrox »

slg wrote: post #7

I really have a hard time putting as much blame on the author as the people in that Github thread are doing. Maybe they could have handled this specific issue a little better, but the underlying problem is just one of the flaws in the open source community that everyone has to accept. Maintaining a project is a lot of work (even just having your name attached to a dead project involves work) and the benefit from doin…

This thread is an amusing rediscovery of the auditing process major companies use before they choose to include open source in their projects. How is it maintained? Who maintains it? What's the risk if it goes rogue? How are updates reviewed? If you think Google simply ingests any random update to their Node dependencies you're crazy.
Post reply on HN