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

221–230 of 1001 posts

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

#221

Post by ratorx »

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…

The tool should take some blame here. I agree that it’s ultimately the developers fault for allowing code to be automatically injected from not fully trusted sources on minor updates, but the package manager makes it way too easy to do.

For example, when I npm install a package, it defaults to specifying a semver compatible version in package.json, rather than doing the secure thing and pinning a version.

But whether this default behaviour should change is not is also a security tradeoff. Pinning versions means that you will keep using an insecure version of a dependency until you update, whereas using a semver compatible version allows you to “automatically” pick up a fixed and compatible version. In practice however with lock files and local caches, the developer always needs to update for security patches anyway.

However, given the current NPM landscape (with packages having numerous small dependencies from a large variety of authors), going towards the former instead of the latter is definitely makes a lot more sense.

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

#222

Post by shukantpal »

gokhan wrote: post #169
sneak wrote: post #57

Earlier quoted context omitted.

When you publish free software you give it away as a gift. That's the point. Expecting compensation for a gift is the error.

It's not the original gift that is the problem, all maintainers start very happy early on but keeping software up while adding more features is costly, someone needs to pay an it's almost always paid by the maintainer in terms of free time. If you intend to keep it as the original gift, it will be called abandoned.

> keeping software up while adding more features is costly

The software maintenance is also given out as a gift. That's a choice.

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

#223

Post by pc86 »

dane-pgp wrote: post #144
throw_m239339 wrote: post #83

Earlier quoted context omitted.

> This is true for npm. After the incident with leftpad, you can't unpublish anymore. You can, however, publish a new patch update that completely breaks everything. You absolutely can unpublish, it just requires more steps. If NPM gets a DMCA takedown request they will absolutely have to fulfill it.

> If NPM gets a DMCA takedown request they will absolutely have to fulfill it. Assuming the package is released under a Free Software licence, what grounds would there be for a DMCA takedown? I suppose a developer could include the lyrics to a pop song in their code (possibly encrypted), and then tell the copyright holder about it (since I don't think you can make a DMCA request on behalf of a copyright holder withou…

> but I would hope that such a poison-pill would be caught long before the package became widely depended on.

I'm not sure what about the current open source ecosystem makes you think anyone would catch something like this.

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

#224

Post by xg15 »

superkuh wrote: post #165
fault1 wrote: post #80

Earlier quoted context omitted.

The author of this package was caught with 50lbs of Potassium Nitrate (in the middle of NYC) and a bunch of materials on making bombs and booby traps when his apartment caught fire: 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... He might have been the unibomber in training.…

Quoted post unavailable.

Sorry, this is bullshit.

> When investigators entered Squires' apartment to look further, they found more bomb making items including potassium nitrate.

Magnesium powder, sulfur powder, copper powder, aluminum powder, hobby fuse and mixing cups were also discovered in the home.

"The chemicals separately are what they are, but taken together they can assemble an explosive device," Deputy Commissioner of Intelligence and Counterterrorism John Miller said. "There were books about military explosives, booby traps and other things...What we're looking at here is the totality of the circumstances that raised our concern to a level where we're going to need more investigation."

Does that sound to you like he wanted to make a candy rocket?

You can do chemistry all your want, but attempting to build a bomb, even of the attempt doesn't succeed, is illegal.

At the time of the article, the investigation was still ongoing. That's likely why they were no charges yet.

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

#225

Post by paco3346 »

sillysaurusx wrote: post #195
joshuaissac wrote: post #117

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

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.

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

#226

Post by jffry »

ldjb wrote: post #210
wbl wrote: post #92

Earlier quoted context omitted.

Why does a new version break projects without action by the project owners? In Go you would have to explicitly update to the broken version.

Very often, package installation is automated as part of a build pipeline. So if you want to build and deploy a new version of your software, you'll kick off the pipeline and that could potentially download a newer version of a package than was previously being used. Incidents like this highlight that this may not be the best idea.

If you're using NPM without lockfiles, you're gonna have a bad time with discrepancies between trying things on your dev machine and building things in CI machines.

When you have a package-lock.json NPM will install exactly the same version of everything in your dependency tree, making the CI builds much more like what's on your dev machine (modulo architecture/environment changes)

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

#227

Post by toomanydoubts »

mid-kid wrote: post #81
bcrl wrote: post #55

At some point people need to stop pulling in random unsigned libraries from the internet and deploying them without any review or testing. This chaos seems like it would be entirely preventable with just a small sprinkling of best practices.

Time and time again I'll keep saying this: This problem is only solved with package repositories that require review by a maintainer to publish. Linux distributions solved this ages ago.

This raises an interesting business idea. How much would developers and companies be willing to pay for an npm alternative with human reviewers?

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

#228

Post by rlyshw »

tailspin2019 wrote: post #95
evolve2k wrote: post #30

Earlier quoted context omitted.

Actually in attempting to answer my own question, on other platforms like YouTube and Medium, popular content receives monetary support by virtue of being popular. What if this was addressed at the “platform” level, I’m thinking the package manager here, NPM. If npm had paid plans that would essentially mop up larger corporations they could then auto-distribute funds Spotify style based on “number of listens”. I’d pe…

> If npm had paid plans that would essentially mop up larger corporations they could then auto-distribute funds Spotify style based on “number of listens”. This seems like a pretty decent idea…

Except the Spotify model is also rife with issues. Artists generally hate Spotify and hardly make a living off of “pay per stream”. Most of them still very much depend on tours, merch, and, at the higher level, brand deals to make any money off of their craft.

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

#229

Post by hombre_fatal »

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.

You also have to rely on all of your dependencies doing that for their dependencies and so on. It’s really a mindset/vigilance you need for the whole ecosystem.

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

#230

Post by shukantpal »

deadbunny wrote: post #54
afiori wrote: post #14

Earlier quoted context omitted.

From the point of view of GH the license is irrelevant, what they see is that a project they host is in practice being use to distribute malware.

Printing strings is malware?

In an infinite loop, yes.
Post reply on HN