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

51–60 of 509 posts

Re: Backdoor in event-stream library dependency

#51

Post by benologist »

nmg wrote: post #34
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…

The author's stance is that because it was a volunteer effort, he bears no responsibility for transferring ownership to an unknown third party who wants to commandeer the code used by millions of people. I believe this is false. He also feels that there's nothing anyone can do about it except scramble to control the damage. I believe this is currently true.

The other person set out to subvert node modules, the author was just a target interchangeable with 100,000s of other module maintainers. There are already documented cases of very popular node modules having their passwords compromised so this is probably a form of attack we will see grow significantly more prevalent since these modules can see database credentials, encryption keys etc.

This is also very similar to bad entities obtaining or acquiring browser extensions to discretely poison with spyware and advertising, which happened a lot of times.

Re: Backdoor in event-stream library dependency

#53

Post by ttty »

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.

I'd love to do this, but how can you review thousands of lines of code that changed?

Re: Backdoor in event-stream library dependency

#54

Post by eropple »

nmg wrote: post #34
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…

The author's stance is that because it was a volunteer effort, he bears no responsibility for transferring ownership to an unknown third party who wants to commandeer the code used by millions of people. I believe this is false. He also feels that there's nothing anyone can do about it except scramble to control the damage. I believe this is currently true.

> I believe this is false.

It's literally not, though. That's what the license says. It expressly disclaims any such thing.

If you want somebody to incur responsibility, you have to get them to take it on. You can't just demand it of them.

Fortunately, there is a good way to do exactly this. Did you bring your wallet?

Re: Backdoor in event-stream library dependency

#55

Post by AndrewGaspar »

tschellenbach wrote: post #26

I'm also a little bit pissed with the author of this repo. But seriously, how can you vet everyone contributing to your unmaintained open source project.. Good security scanning and perhaps identity verification on Github could help. So at least you can ignore pull requests from authors that didn't verify their identity.

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.

Re: Backdoor in event-stream library dependency

#56

Post by twodave »

dmortin wrote: post #22
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.

If you have tons of depedencies then it's not feasible to check every diff. You may able to do it or pay someone if you are a bigger organization, but a small shop or solo developer can't do this.

Maybe not, but you can avoid updating unless necessary. Assuming you only make necessary updates (and at least do a cursory check at the time) and vet any newly added-dependencies as you go, you can greatly reduce your own attack surface. You're still probably vulnerable to dependency changes up the chain, but then at least you're depending on a community that is ostensibly trustworthy (i.e. if every maintainer at least feels good about their top-level dependencies then the whole tree should be trustworthy).

Re: Backdoor in event-stream library dependency

#57

Post by dmortin »

choward wrote: post #35
dmortin wrote: post #22

Earlier quoted context omitted.

If you have tons of depedencies then it's not feasible to check every diff. You may able to do it or pay someone if you are a bigger organization, but a small shop or solo developer can't do this.

That's why you lock your dependencies.

Dependencies need bugfixes and you may even want to use new features, so locking is not a permanent solution.

Re: Backdoor in event-stream library dependency

#58

Post by ocdtrekkie »

tschellenbach wrote: post #26

I'm also a little bit pissed with the author of this repo. But seriously, how can you vet everyone contributing to your unmaintained open source project.. Good security scanning and perhaps identity verification on Github could help. So at least you can ignore pull requests from authors that didn't verify their identity.

You can't vet the people, but you can vet the code. Of course, if you just give someone commit rights, then you can't. But generally speaking the maintainer understands the code they merge into a project, and that is the vetting that takes place.

Re: Backdoor in event-stream library dependency

#59

Post by lmm »

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.

Lack of code signing is what's harmful here.

My maven projects' dependencies are technically all pinned, but updates are just a "mvn versions:use-latest-releases" away. But, crucially, I have a file that lists which GPG key IDs I trust to publish which artifacts. If the maintainer changes, the new maintainer will sign with their key instead, my builds will (configurably) fail, and I can review and decide whether I want to trust the new maintainer or not.

Of course, NPM maintainers steadfastly refuse to implement any kind of code signing support...

Re: Backdoor in event-stream library dependency

#60

Post by kofejnik »

dmortin wrote: post #13
kofejnik wrote: post #6

Earlier quoted context omitted.

check them into your git

How does that help? You still update from time to time get fixes, new features and then you can get some unwanted code which is not discovered yet.

it enables you to run git diff after updating your npm dependencies, so you at least have a chance to detect something shady
Post reply on HN