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

31–40 of 509 posts

Re: Backdoor in event-stream library dependency

#31

Post by SpicyLemonZest »

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…

No. Transferring a project wholesale to an unknown maintainer is effectively a fork; I'd much rather have my dependencies die than start silently pulling in a fork. If I want to swap in right9ctrl/event-stream, I'll do it myself.

Re: Backdoor in event-stream library dependency

#32

Post by bluehatbrit »

bcherny wrote: post #9

It looks like no one is even sure what the code actually does? Or am I misreading that thread.

Seems correct, the payload is encrypted with AES and it seems that a package.json description is the passphrase but the issue author hasn't been able to decrypt it so far (for reasons listed in the issue).

Re: Backdoor in event-stream library dependency

#33

Post by iforgotpassword »

cellis wrote: post #5

Is there a way to get stats on suspicious activity on NPM repos? I feel like this is a service that every node.js project is in need of after left-pad and now this.

Don't forget getcookies backdoor: https://blog.npmjs.org/post/173526807575/reported-malicious-...

Re: Backdoor in event-stream library dependency

#34

Post by nmg »

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.

Re: Backdoor in event-stream library dependency

#35

Post by choward »

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.

That's why you lock your dependencies.

Re: Backdoor in event-stream library dependency

#36

Post by _wmd »

ericcholis wrote: post #23
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…

It's better if the new maintainer's intentions are altruistic. From @dominictarr, the maintainer: > 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. That's just plain irresponsible. He must have known how popular the library was. Taking ownership of browser extensions and common soft…

This is entitlement speaking, and it's clearly a solution that doesn't scale. Downstream must be responsible for only depending on software from reputable sources, there simply is no alternative.

I hate to have to do this, but the requirement runs right to the core of how this development model functions whatsoever:

    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
    AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
    DEALINGS IN THE SOFTWARE.
I'd suggest one problem here is a user interface / packaging model issue: end users / downstreams may override the version choices made by their upstream dependencies. In the case here, the reputability of that upstream varied over time. Permitting version locking allows a chain of reputability to be exist, allowing a limited amount of trustworthiness to be imparted by upstream's selection of dependencies ("I trust this guy's package, so I trust all their dependencies too")

Re: Backdoor in event-stream library dependency

#37

Post by reacweb »

ericcholis wrote: post #23
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…

It's better if the new maintainer's intentions are altruistic. From @dominictarr, the maintainer: > 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. That's just plain irresponsible. He must have known how popular the library was. Taking ownership of browser extensions and common soft…

Maybe it should be easier to give monetary rewards so that popular module maintainers get more motivation to care.

Re: Backdoor in event-stream library dependency

#38

Post by jamp897 »

This is one of the gaping security holes that open source has always had, you don’t know where the code came from and your best indication if it’s safe is how popular it is. Npm and Maven libs being the scariest since there are hundreds for even small apps.

Re: Backdoor in event-stream library dependency

#39

Post by raesene9 »

ghostly_s wrote: post #10
dmortin wrote: post #4

I guess it's not npm specific, because the same thing can happen in any other open source repo, can't it? Some guy takes over maintenance of a dormant package and then adds code which no one bothers to check.

Well, not really. Anyone can "take it over" in the sense of creating a new, maintained fork, but the various distro package managers have policies that I think generally require some review/approval process to transfer ownership of a package they publish. I don't know anything about NPM, but imagine it's a more lax process than something like Debian. It sounds like the maintainer here did something shady or simply re…

there's a split here.

Linux package managers (by and large) have a maintenance process.

Programming language package managers, by and large, do not

So this could happen on rubygems, PyPi, Nuget, etc

Re: Backdoor in event-stream library dependency

#40

Post by luizfzs »

rdtsc wrote: post #3

Also note the same user owns this library: https://github.com/right9ctrl/node-scrypt I would be very suspicious of that as well and audit anything that library has touched.

I'm not a crypto guy but this change really makes me scratch my head: https://github.com/right9ctrl/node-scrypt/commit/52a1cb792bc...
Post reply on HN