Live data from Hacker News

Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

bleepingcomputer.com

411–420 of 1001 posts

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#411

The software industry doesn't have any standards about how to publish or consume software, and that leads to problems like these (not the conflict over OSS, but the ability for random upstream software to randomly compromise thousands of other projects). We all live in this 'wild wild west' of software that has no guarantees of quality or safety or rigor. We could really use a regulated license for software developme…

> The software industry doesn't have any standards about how to publish or consume software, and that leads to problems like these (not the conflict over OSS, but the ability for random upstream software to randomly compromise thousands of other projects).

The publishing side is irrelevant. Anybody can make any package available for free on the internet. The unwillingness of some private businesses, often billion dollar companies, to audit and vet libraries because obviously, it costs money and these businesses use open source as a way to cut cost at first place, is the issue. The entitlement.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#412

Some people find this too rough, but the reality is: do not license something as MIT or any free license if you are not happy with commercial users benefiting from your work . Simple as that. None of them are under any obligation to pay, maintain, promote, or not clone your project.

This goes both ways. Don't blindly use MIT licensed code if you aren't okay with the risk of something breaking or something malicious being inserted.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#414

GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724

People who are upset that GitHub suspended him: would you still be upset if the contents of the new package were "require('child_process').exec('rm -rf /*');"? If not, then how malicious does code have to be before a suspension is okay in your opinion?

What are the set of commits that GitHub should allow people to make to repos that they solely own?

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#415

GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724

This is not the way. Github doesn't have the right to tell someone what to do with their own code. The only right thing to do in this situation is to fork the repositories and fix the situation on the npm side. Github doesn't get to ban this guy because he took a dump in his own backyard. EDIT: I suppose the literal DoS attack in the code probably puts him squarely in the "malicious behaviour" category which then giv…

>Github doesn't get to ban this guy because he took a dump in his own backyard.

Yes they most certainly do.

Also, his landlord gets to ban this guy because he was building bombs in his apartment.

https://abc7ny.com/suspicious-package-queens-astoria-fire/64...

https://www.qgazette.com/articles/more-charges-possible-for-...

https://nypost.com/2020/09/16/resident-of-nyc-home-with-susp...

https://www.reuters.com/article/us-usa-new-york-bomb/new-yor...

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#416

Earlier quoted context omitted.

> People who are upset that GitHub suspended him: would you still be upset if the contents of the new package were "require('child_process').exec('rm -rf /*');"? If not, then how malicious does code have to be before a suspension is okay in your opinion? Microsoft owns both Github and NPM. There is an obvious conflict of interest here.

... it’s not obvious to me?

> ... it’s not obvious to me?

If the source was maintained on Bitbucket, why the hell would bitbucket nuke the developer's account access? That's not their problem what happens on NPM.

Github and NPM are defacto the exact same company on the other hand. Github actions are in retaliation of NPM "mispublishing".

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#417

Earlier quoted context omitted.

This is scary, and I don’t know why people here aren’t losing their minds. I think someone should make a big deal about this. What would be the first step? On the other hand, my GitHub was once suspended (and all repos shuttered) for posting gists that looked like spam to some algorithm. It was extremely unsettling, and they need to do a better job communicating. But they may have suspended the account because they t…

I assume GitHub initially saw this as someone gaining unauthorized access to his account. How often does a maintainer add something like this? Without knowing it was actually him I can totally see why they'd think it wasn't a proper update.

I don't assume that at all.

I assume that GitHub now lives in Microsoft-liability-fear mode. Expect them to police commits in popular projects.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#418
post #277

Earlier quoted context omitted.

Why is that scary? If you do bad things, you're going to get banned. This guy abused Github to distribute malicious code to thousands of projects. If losing your Github means losing your projects, that's on you for being lazy/irresponsible with them. Git is already decentralized, and anything important should be cloned on something you own.

> This guy abused Github to distribute malicious code to thousands of projects. He could've done far, far worse in terms of the technical impact of these changes. It's obvious that he was trying to make a statement, not exfiltrate data to sell on the dark web. It's scary because, as a FOSS maintainer, your code is your responsibility to do with what you will until it's no longer in the market's interest. You don't ha…

This wasn't a "protester". It was deliberate sabotage, done with full knowledge that it would cause major damage. GitHub is with its rights to kick this guy off. It would even be within its rights to take over that account and fix the introduced bug (by reverting the change or otherwise). That wouldn't prevent the original developer from maintaining their own broken version, but npm and GitHub could eliminate it if they want.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#419

GitHub has now suspended the maintainer: https://nitter.net/marak/status/1479200803948830724

If that is true it's an outrageous overreaction by GH. Are they now gatekeeping the kinds of code changes you can make to your own repo?

It isn't your own if you host it with them, and they aren't obliged to help you commit sabotage.

Re: Dev corrupts NPM libs 'colors' and 'faker', breaking thousands of apps

#420
post #153

Earlier quoted context omitted.

Dependencies are a major attack vector now. Tread carefully with all the supply chain attacks out there, it might not even be the authors doing these. We are entering a dependency attack massive war. Dependencies are a balance but also a sign of weakness of a system in the modern day. There at least needs to be delayed, dependency bot like analysis before you integrate. Even then, they just leave your systems open to…

How about using dependencies but pinning the version and only updating if you know what the update contains? I'm still continually baffled that we ended up in a world where automatically accepting updates from every dev and their dog is not just the norm but recommended practice.

> if you know what the update contains?

I think anyone who thinks they're doing this is fooling themselves. You can review code for accidental vulnerabilities but if someone is trying to slip in a backdoor it shouldn't be hard to do so in a stealthy manner.

The reality is that the entire dependency concept is just broken. There is an implicit trust that all dependencies are equally trusted. Your logging package is just as capable of performing file and network operations as your http package, even if you assume it won't.

That's silly.

It is up to programming languages and package managers to solve these problems. They're also not that hard to solve, in my opinion. "Run arbitrary code on a computer" is a model we've been securing for decades with web browsers, both in terms of web pages and extensions, and now too with mobile.

Solving "this code can do X but that code shouldn't be able to" is similarly easy to solve with languages that support effects or capabilities.

It just hasn't been done yet.

Post reply on HN