Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bleepingcomputer.com

Post reply on HN
Print view View original

301–310 of 1001 posts

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

#301

Post by javchz »

I think as JS developers, this should be a wake-up call, to never trust npm semantic versioning if your project it's critical.

In this case, it's a dev who decided to use his right of doing political activism at the cost of his reputation. But this it's a best-case scenario. Another dev of a popular NPM library could get hacked, and insert malware.

I wonder if there are zombie servers out there mining crypto or doing DDoS, just because an obscure library dependency of a dependency of a dependency, got compromised.

I don't think Marak was "right" (In bird culture that is considered a d*ck move), but legally he owned nothing to anyone. Adding a new update to production without testing first, it's in the hands of their devs of the apps, not him.

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

#302

Post by aahortwwy »

Beta-7 wrote: post #137
Flocular wrote: post #78

Imagine they introduced something worse. Could any developer explain to a manager why you needed to import this package? "Why do we need colors there?", "Why can't we make that colored ourself?"

At my last job we (InfoSec) had the devs fill out "ownership" forms for when they want to include something third-party into the product. Other than forcing the team to do due diligence on the third-party it also made them responsible for keeping it secure and them the people "at fault" if something went wrong due to it. While it was seen as an unnecessary hurdle set up by us I hope it started some meaningful convers…

These sorts of "security" measures kill productivity and ultimately accrue (along with others) to the point where your organization moves so slowly that its lunch gets eaten by upstart competitors who aren't burdened by self-imposed make-work.

I've seen it happen.*

EDIT: * While working in infosec, I'll add.

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

#303

Post by tkiolp4 »

IceDane wrote: post #186
joshuaissac wrote: post #117

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…

From Github’s TOS

> GitHub hosts a wide variety of collaborative projects from all over the world, and that collaboration only works when our users are able to work together in good faith. While using the service, you must follow the terms of this section, which include some restrictions on content you can post, conduct on the service, and other limitations. In short, be excellent to each other.

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

#305

Post by kseifried »

CVE probably won't do CVEs for these as they don't do backdoors/intentionally malicious code (but maybe they will, who knows). In any event the color.js issue is being tracked by the #GSD https://globalsecuritydatabase.org/ in GSD-2022-1000007 (https://github.com/cloudsecurityalliance/gsd-database/blob/m...) and the faker.js issue in GSD-2022-1000008 (https://github.com/cloudsecurityalliance/gsd-database/blob/m...), if you would like to add anything to it please submit a PR or file an issue against the file. Thanks.

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

#306

Post by bogwog »

skeeter2020 wrote: post #254
ricardobeat wrote: post #188

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.

Also let's keep in mind that these projects would never have achieved their level of popularity if they were not licensed liberally. The value he's provided was based on free; you can't then compare it to the alternative after the fact.

This guy wants to have his cake and eat it too.

I saw a project recently where the author released it to the public domain, but in the top he said something like "I know it's public domain, but please don't remove my name."

Sometimes people choose a liberal license like CC0 or MIT because they don't want to bother researching the boring details of licensing and/or don't care. But clearly that guy who wants his name on it, and the dev in the OP do care about the licensing details.

Releasing colors/faker under a liberal license was a mistake, and pushing out this malicious update was another (much worse) mistake.

What he should have done was updated his libraries to print out a warning like "This software has reached end-of-life and will no longer be maintained. It is being superseded by Colors PRO. Visit ... for more information.", and then started selling licenses/support contracts.

But now, not only is he not going to get paid for colors/faker, he probably won't ever get hired by any of the companies affected by this, he might get sued, and he might even go to prison if this gets misconstrued as hacking.

EDIT: Ok, after some more research, it looks like this guy is going through some serious shit: https://news.ycombinator.com/item?id=29868071

Everything I wrote up there was based on the assumption that he wasn't trying to build a bomb in his apartment...my bad.

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

#307

Post by ec109685 »

notRobot wrote: post #21

Here's my $.02: Packages are literally remote code exec vulns in the hands of package authors. At the very least, it takes them under a minute to break your app, simply by deleting their package. Read the article. This is not the first time it's happened, and it's not going to be the last. [0] I write backends (mostly in PHP, although not exclusively), and I release a lot of my code under libre licenses. But I don't…

I’m surprised the AWS SDK doesn’t pin its dependencies and put new versions through its paces before letting end users possibly use a compromised utility with catastrophic results.

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

#308

Post by dane-pgp »

bcrl wrote: post #282
bcrl wrote: post #215

Earlier quoted context omitted.

Requiring multiple signatures from several trusted sources would have.

I'm seriously downvoted for this? We have just had an incident where a maintainer acted maliciously and has demonstrated that a single point of trust is insufficient. If we really care about avoiding issues with open source software, clearly it is necessary to get multiple maintainers to sign off on changes to widely used open source projects. We have had all the technology components needed to implement this for dec…

I'm saddened to see you getting downvoted too (and I've tried to compensate for that). You're right that more ecosystems need something like Crev:

https://dpc.pw/cargo-crev-and-rust-2019-fearless-code-reuse

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

#309

Post by jbverschoor »

xg15 wrote: post #153
drawkbox wrote: post #97

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.

Yeah I also don’t understand. But then again.. the js ecosystem is one big pile of turds..

Tech cycles with people who reinvent the wheel and keep making the same mistakes

All these problems have long been solved

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

#310

Post by andrew_ »

gfykvfyxgc wrote: post #3

I don’t understand the mindset of open source developers who dedicate significant time energy and life to free software, unless there’s a tangible, quantifiable advantage to doing so. That advantage may well be indirect such as reputational or learning. I just don’t grasp why people do it for nothing, to the advantage of large companies.

Because it's fun ya mook. That's it. That's the reason.

It's fun to tinker. It's fun to put things out there into the ether. It's fun to exercise the brain and try new things and learn new ways to do things and publish things. The second it stops being fun, we stop.

Post reply on HN