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

731–740 of 1001 posts

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

#731

Post by lrvick »

pc86 wrote: post #179
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…

Are these really RCE vulnerabilities? Looking at it systematically I only see this as an RCE vector if you're doing one or more things very wrong. This assumes that packages are immutable and an author can't update a version that's already there. This is how NuGet works, and IMO is how any remotely sane package manager will work. There's no reason for a version to be mutable in this context. Pegging to a specific ver…

If you are not updating daily any typical webapp tree will accumulate known vulns.

Holding back updates is not a sane strategy either. You must review all the new patched versions of all dependencies daily or, failing that, do the work once to drop all the deps you can not afford to maintain reviews for.

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

#732

Post by Taurenking »

lenkite wrote: post #695
obviousanswer9 wrote: post #642

Earlier quoted context omitted.

Quoted post unavailable.

The author should first change his LICENSE before he does crap like this. Make sure the terms of the license upfront state that "billion/trillion dollar companies" are not permitted to use this library. Stop using the MIT license for your hactivist project.

No post body was provided.

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

#733

Post by r_hoods_ghost »

Good on him. While the foss movement may have started with good intentions its main achievement has been to help accelerate the transfer of wealth from the producers of software to rentiers and parasite capitalists by providing them with a truly vast amount of free labour. Be a radical! Demand to be paid for your work!

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

#734

Post by 0x0nyandesu »

lrvick wrote: post #722
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…

Security auditor here. Every time I see a client importing unsigned code with no evidence anyone they trust has reviewed it, I flag it as a supply chain attack vector in their audit and recommend mitigations. Some roll their eyes, but I will continue to defend it is a serious issue almost every company has, particularly since I have exploited this multiple times to prove a point by buying a lapsed domain name that mi…

You can say the same thing about the entire Linux stack

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

#737

Post by mirekrusin »

pmlnr wrote: post #248
mirekrusin wrote: post #231

Earlier quoted context omitted.

Adding this kind of disclaimer notice doesn't mean you can do whatever you want. If you perform action in obviously bad faith, your account will be suspended – it's very simple. Github's terms of service must have somewhere detailed description about it.

> Github's terms of service must have somewhere detailed description about it. Please, point me to the part where bugs, intentional or not, are disallowed. Taking over someone's account is not justified; for this, definitely, but I'd say it's never is. Block the account yes; take over, no.

You are conflating bugs with malicious code. If somebody decides to deliberately create harm, intentions are very clear, there is no point in playing stupid to turn it around into a bug, it doesn't work in courts, it won't work here either. There should be no place for this kind of immature behaviour in github/npm communities. Account suspension and reversal of harmful actions feels like adequate steps taken to protect everybody.

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

#738

Post by cerved »

deathanatos wrote: post #537
cerved wrote: post #99

Earlier quoted context omitted.

look at diffs?

I actually do this, on occasion. (Not 100%, and not to a degree I'd say "yeah, I'd've caught this colors/fakers thing." But enough to say that I've seen a decent sample.) There is literally, on average, no difference in average quality between commits on FOSS projects, and commits on projects we pay external entities for. Some paid projects are just crap code, and some FOSS code is extremely high quality. I've had to…

> I have no idea how to solve the root problem here

I'm not even sure what the problem is. If it's "updating dependencies introduces severe side effects" wich, I think, should be accounted for in the process

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

#739

Post by mazlix »

junon wrote: post #455

Maintainer of Chalk[0][1] here, a very popular alternative to colors. Happy to help anyone that would like to port away from colors to chalk, or who might just have general questions about terminal colors. Just reply here and I'll see them. [0] https://GitHub.com/chalk/chalk [1] https://npmjs.org/package/chalk

Never used colorjs, have used chalk in my OSS projects and love it. Guess now's a good time show appreciation to maintainers so thank you.

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

#740

Post by mPReDiToR »

0x0nyandesu wrote: post #734
lrvick wrote: post #722

Earlier quoted context omitted.

Security auditor here. Every time I see a client importing unsigned code with no evidence anyone they trust has reviewed it, I flag it as a supply chain attack vector in their audit and recommend mitigations. Some roll their eyes, but I will continue to defend it is a serious issue almost every company has, particularly since I have exploited this multiple times to prove a point by buying a lapsed domain name that mi…

You can say the same thing about the entire Linux stack

Unless you're using LFS, of course.

The problem you describe isn't Linux, it's Linux Distributions.

Where would you draw the line?

Source packages are available, and if the binaries don't match the code a distro would soon be outed a la "many eyes" thinking.

We have to trust some or none.

Get the top off that chip, see if the factory put an extra core in for the NSA (IME).

Post reply on HN