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

411–420 of 509 posts

Re: Backdoor in event-stream library dependency

#411

Post by fishywang »

StavrosK wrote: post #29

I had this exact same problem from both sides (not working on a project any more and wanting to find someone to maintain it/wanting to maintain a project someone wasn't working on because I found it interesting). It's not always easy to find people who are interested, and, while giving maintainer access to someone you know very little is usually fine and works out great, sometimes you get results like these. In the e…

If you are a maintainer of a project that you want to move on, what's the problem of adding this to README: "This project is abandoned/no longer maintained.", and optionally "Here's a known fork but I haven't vetted the code so if you use the fork you are AT YOUR OWN RISK: ", and when someone asks you to transfer ownership, you just tell them that they can fork it? Is it because of the "namespace" issue in some package management systems (e.g. NPM) that the forks can't get the nicer name?

Re: Backdoor in event-stream library dependency

#412

Post by zawerf »

gnulinux wrote: post #402
zawerf wrote: post #387

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…

For what it's worth: it'd be undecidable to catch all vulnerabilities even if you very precisely define the semantics of your virtual machine, because it'd require knowing whether a certain line of code will be executed, which is known to be as hard as the halting problem. Practically, maybe? Maybe one can use ML to check codebase for suspicious code. But in an ecosystem like npm no matter what protection you have ag…

Not really asking for perfect/decidable.

Just wondering out loud on how to detect even one of the other active exploits that are surely in the wild. This one was live for 3-4 months before it got found by luck?

For example I would really appreciate if they added something to detect/warn when a package needs eval or http requests permissions (yes, I know npm packages don't have a concept of permissions).

Anyway your commonly repeated advice on how to defend yourself isn't practical (short of not using npm). The dependency that got me was nodemon. That ought to be "trusted code" with 17k github stars, 1 million downloads per week but apparently not. As I said already, even if I did check the commits to all my dependencies, I don't think I would've caught this one. It's a one line change in the minified build file of a transitive dependency nested 4 deep. All the commits around it are very normal looking.

Re: Backdoor in event-stream library dependency

#413

Post by michaelmrose »

jodrellblank wrote: post #308
michaelmrose wrote: post #132

Earlier quoted context omitted.

If you run a business where you have convinced people to give you access to their house to do some chore and you sell your business and your copy of their keys to a criminal it could be morally problematic. A car is merely a fungible vehicle the customer would have been no better or worse off had the robber been driving a different car. This would be an apt analogy for just giving / selling a code base. Had it been d…

He is morally liable Google says "Definition of Liable: responsible by law; legally answerable". If you claim he's not legally responsible but is "morally liable", where "liable" itself means "legally responsible", what in your world does the term "morally liable" mean, specifically? What does it mean you can do to him, or what does it mean you should do in future in response to this?

Google isn't the ultimate source of truth of the meaning of words. When someone says that another party is morally liable they mean morally responsible. That he ought to feel responsible and act according and consider others actions in the future lest he feel like he has morally failed people in the future. Ultimately we are often and are often expected to be our harshest critic and ought not to limit our duty to others to the minimum that the law requires.

Re: Backdoor in event-stream library dependency

#414

Post by StavrosK »

fishywang wrote: post #411
StavrosK wrote: post #29

I had this exact same problem from both sides (not working on a project any more and wanting to find someone to maintain it/wanting to maintain a project someone wasn't working on because I found it interesting). It's not always easy to find people who are interested, and, while giving maintainer access to someone you know very little is usually fine and works out great, sometimes you get results like these. In the e…

If you are a maintainer of a project that you want to move on, what's the problem of adding this to README: "This project is abandoned/no longer maintained.", and optionally "Here's a known fork but I haven't vetted the code so if you use the fork you are AT YOUR OWN RISK: ", and when someone asks you to transfer ownership, you just tell them that they can fork it? Is it because of the "namespace" issue in some packa…

It's half the namespace issue (the release package name sometimes needs to be added) and half that maybe you haven't agreed with some fork that you will make it the official one beforehand. Maybe there isn't even a fork like that.

Besides, projects don't usually go from active to completely unmaintained. Adding it to the Code Shelter is a nice way to solve this when you see development slow down, because you basically have nothing to lose.

Re: Backdoor in event-stream library dependency

#415

Post by rglover »

trickstra wrote: post #407
rglover wrote: post #310

That thread is a huge argument for paid software. It's mind blowing how folks expect people to maintain things for nothing and get mad when it doesn't work perfectly. Some silly choices were made by the original maintainer but give the dude a break. He doesn't owe you a damn thing.

do you know how many of your paid software contains a similar disclaimer that removes their responsibility for the damages caused by the software? Only you'd never have a chance to look at that code and find this injection...

You're not wrong; quite right, in fact.

My point here is less about payment guaranteeing a lack of bugs or having someone to point a finger at and more at incentivizing the team building it to fix things quickly. Of course, there's always the problem, but that's a case-by-case issue.

Re: Backdoor in event-stream library dependency

#416

Post by gnulinux »

Severian wrote: post #328
AdmiralAsshat wrote: post #207

Seems like we need a linter that can look for binary, hex, or otherwise encrypted-looking data in source code (I have no idea how you'd teach the linter to look for anything that "looks like gibberish"--I'd leave that to people smarter than me). From past experience with other popular apps that get backdoored with bitcoin miners, anything intentionally obfuscated in what is supposed to be an open source application i…

You could measure the entropy of single lines and determine if the entropy is high. Although you'd probably get a lot of false positive.

You can probably just measure the entropy of literals, but then an attacker might use reflection to construct arbitrary strings. Not an easy problem.

Re: Backdoor in event-stream library dependency

#417

Post by gnulinux »

jrochkind1 wrote: post #393
igolden wrote: post #376

Earlier quoted context omitted.

A random, lucky find: https://github.com/remy/nodemon/issues/1442

Interesting. If the malware hadn't buggily triggered a deprecation warning...

Makes you think how many backdoors out there like this.

Re: Backdoor in event-stream library dependency

#418

Post by no_one_ever »

trickstra wrote: post #407
rglover wrote: post #310

That thread is a huge argument for paid software. It's mind blowing how folks expect people to maintain things for nothing and get mad when it doesn't work perfectly. Some silly choices were made by the original maintainer but give the dude a break. He doesn't owe you a damn thing.

do you know how many of your paid software contains a similar disclaimer that removes their responsibility for the damages caused by the software? Only you'd never have a chance to look at that code and find this injection...

Yes but then you have someone culpable for their mistake.

Re: Backdoor in event-stream library dependency

#419

Post by tclancy »

meowface wrote: post #160
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…

Handing over a popular software project to a random stranger you've never spoken to who asks to take it over is just irresponsible. Nothing is preventing that stranger from adding malicious code and potentially compromising millions of devices, which is exactly what happened.

Have you ever created a package that people started to use, which you then had to maintain for purposes that didn't do anything for you and then no longer even need the package? Pretty much any rando offering to take over maintenance is going to be welcome to it compared to the dozens of requests and insults offered as bug reports.

Re: Backdoor in event-stream library dependency

#420

Post by Aeolun »

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…

I don’t know, if I write open source software, the only definition of success I use is whether or not I had any fun writing it.

Anything else is gravy.

Post reply on HN