Backdoor in event-stream library dependency • Hacker News Board

Re: Backdoor in event-stream library dependency

#471

Post by spondyl » Tue, Nov 27, 2018, 6:08 AM UTC

This whole debacle has been really interesting.

I've personally met Dominic and chatted with him in the past (although I doubt he would remember me) and he's a great guy. I may not agree with his world views but he's respectable.

Just giving away a repo, and reading his description of it, sounds like something he would do, haha. I'm sure from his view, he's just been open sourcing experimental modules (however big or small) and that's all it is: fun

On the flipside, the inhouse CSS framework where I work actually pulls in event-stream as a sub-sub-subdependency which could have bitten us possibly if the attack wasn't so specific.

It's easily to blame Dominic but ultimately, he's just a guy who made some code for fun and people started using it.

I'm sure when you're in a position like that, one of two things is likely:

1) You either don't look at download/usage analytics because why would you? It's one of many projects and you're not measuring their success by anything more than how you feel. People can use whatever code but it's not exactly a product being sold

or

2) You do look at the numbers perhaps but 2 million people? How do you even quantify that? It could be 1 million bots, 2 million hobbyists, 50,000 enterprises who don't cache internally and npm install over and over, or even all 3 combined!

Anyway, this whole event hasn't happened in a vacuum so at least it'll (hopefully) spark constructive discussion about the state of JS and companies/projects relying on possibly unmaintained sub-sub-sub... you know

Re: Backdoor in event-stream library dependency

#472

Post by candybar » Tue, Nov 27, 2018, 6:43 AM UTC

dragonwriter wrote: post #189

raesene9 wrote: post #179

Earlier quoted context omitted.

You honestly think that the author of software released as open source is going to be liable for vulnerabilities in that software ... really? If that were the case, you'd pretty much wipe out the software industry as it stands today :) I'd be very interested in case law where you can see the users of a service (which might not even disclose what software they use) are able to sue the author of a package used as part…

> You honestly think that the author of software released as open source is going to be liable for vulnerabilities in that software Where the type of harm that results is reasonably foreseeable and could have been prevented by reasonable care by the developer (or maintainer; different though often co-occurring roles), I don't see how the general law of negligence doesn't fit. AFAIK, negligence has no open source soft…

IANAL but I see two issues here. First, you still have to show that he had the duty to act, which is quite problematic given that there was no relationship between the parties beyond an open source license which expressly disclaims any liability. There's no relationship between the end users and the library maintainer and for any specific instance of the harm, it's difficult to argue that the end user, whose connection to the library is merely that whoever wrote the software happened to use the library, is owed some duty by the library maintainer. Likewise, the idea that the library maintainer should have foreseen this harm, given that the library maintainer likely has no idea how the library is being used, seems far-fetched.

Second, since software engineering is not a licensed profession, for any related conduct to be seen as negligent, it has to be something that a reasonable person should be able to avoid and foresee that could cause specific harm. Even a relatively gross act of incompetence by any reasonable engineering standards likely does not meet this bar, given that there's no license required for someone to be in this situation and that it takes a lot of expertise to understand how specific bad practices could cause harm.

Re: Backdoor in event-stream library dependency

#473

Post by komali2 » Tue, Nov 27, 2018, 7:00 AM UTC

brobdingnagians wrote: post #384

codetrotter wrote: post #159

Earlier quoted context omitted.

> 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…

This sounds like "if it's not perfect, it's a failure."

I'm actually not aware of a single piece of software that didn't at some point have a production security vulnerability.

Facebook failed.

Google failed.

Amazon failed.

Re: Backdoor in event-stream library dependency

#474

Post by onion2k » Tue, Nov 27, 2018, 7:06 AM UTC

skore wrote: post #305

codetrotter wrote: post #159

Earlier quoted context omitted.

> 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…

> He talks about creating a community where anyone is welcome to contribute. Yes and in this case, that was exactly the problem. > It is perfectly fine for an open source project to have the development process and the community as its raison d'être. Conway's law is not an instruction manual.

The problem was that too few people contributed. A contribution to an open source project doesn't have to be a pull request. Glancing over the code you're pulling down rather than assuming the maintainer is infallible counts just fine. Very, very few people do that in the JS ecosystem though.

When a package gets 2m downloads a day and it still takes 2 and a half months to find a problem, a huge number of developers have failed to do their part.

Re: Backdoor in event-stream library dependency

#475

Post by Ayesh » Tue, Nov 27, 2018, 7:26 AM UTC

slg wrote: post #399

WorldMaker wrote: post #378

Earlier quoted context omitted.

A lot of users had it locked to a semver major version or major.minor version, which isn't necessarily trusting the maintainer "in perpetuity", just the current development track. Is a change between maintainers a semver-major breaking change? Several people have suggested that that is a baseline that npm could easily automate/enforce. That would have at least sent a community signal to re-review/re-audit the package…

Does npm currently control versioning to any extent? A quick Google search seemed to show that they only make versioning recommendations with no real rules. If you are operating from the premise that the maintainer is potentially compromised, why would you trust them to stick to the semantic versioning spec?

You publish the packages from a directory. While npm supports VCSs, it's not a requirement.

Re: Backdoor in event-stream library dependency

#476

Post by watwut » Tue, Nov 27, 2018, 7:37 AM UTC

programmarchy wrote: post #123

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…

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…

What happened is that Dominic gave ownership to the only person who wanted it: "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." At every single point, there was authority and responsibility. It is just that authority turned out to be bad actor.

It was situation where former authority was not interested in being authority anymore, since former authority gained nothing from it and had other work.

Re: Backdoor in event-stream library dependency

#477

Post by watwut » Tue, Nov 27, 2018, 7:39 AM UTC

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…

Security vulnerabilities due to not updating are more likely then those from library being intentionally hostile.

Re: Backdoor in event-stream library dependency

#478

Post by onion2k » Tue, Nov 27, 2018, 7:42 AM UTC

Ayesh wrote: post #469

slg wrote: post #397

Earlier quoted context omitted.

I am generally advocating for being an informed user of open source software. As for something more specific, I would echo the two suggestions from the original author in one of his Github comments: >1. Pay the maintainers!! Only depend on modules that you know are definitely maintained! >2. When you depend on something, you should take part in maintaining it. You can't expect someone to maintain your code for you wi…

I suppose this is hard in NPM. For example of I have a project with 5 dependencies, this explodes to hundreds of tiny projects. These individual projects are almost always just a few lines of code, and there's no way anyone's going to become a donor for them. Many major projects are well funded (webpack, etc), but all it takes is one of those tiny packages to send a malware.

That isn't a problem. You pay the maintainers of the packages you use, and they pass on some of that money to the maintainers of the packages they use. If a problem like this one happens they'll lose a lot of customers, so they're incentivized to audit the code they're pulling down.

You only need to worry about the level immediately below yours.

Re: Backdoor in event-stream library dependency

#479

Post by slavik81 » Tue, Nov 27, 2018, 7:54 AM UTC

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…

The core utilities are provided as a suite. The cat utility is one of a hundred others, all packaged together. Even without distributions, you'd only need to vet one organization for those basic utilities.

Re: Backdoor in event-stream library dependency

#480

Post by AnaniasAnanas » Tue, Nov 27, 2018, 7:59 AM UTC

meowface wrote: post #298

AnaniasAnanas wrote: post #259

Earlier quoted context omitted.

To be honest that kind of your fault for trusting that code. Heck, the commits were not even signed as far as I know, had they been signed the change of "ownership" would have been clear.

Makes no difference if they were signed or not. He handed over the NPM package, not the GitHub repo. NPM doesn't show commit history or authors and has no connection to GitHub; you can easily have a GitHub repo for your NPM package with benign code in the GH repo and completely different, malicious code in the package.

> not the GitHub repo

He did that too actually.

> you can easily have a GitHub repo for your NPM package with benign code in the GH repo and completely different, malicious code in the package

This is one of the biggest issues that NPM has, along with not enforcing packages to be signed. If the package was signed this would not be an issue as people would see that the signer changed.