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

831–840 of 1001 posts

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

#831

Post by IgorPartola »

newaccount74 wrote: post #821
heurisko wrote: post #762

Earlier quoted context omitted.

> it is recommended prominently in multiple places that they not blindly trust the code and actually inspect it before using it. The friction in this process is intended. There is nothing inherent in using packages that means you have to blindly trust the code, neither does providing a package mean you have to accept any more responsibility over providing a .php file (packages are just .php files with a few metadata…

> There is nothing inherent in using packages that means you have to blindly trust the code I use about a dozen different package managers and I have no idea how to check the code they download before they install/deploy it. I often check the source on Github if I need to look something up, but I have no idea how I'd go about verifying that the code on Github is the same as whatever the package managers install.

That sounds like a personal problem. .deb and .rpm packages are nothing more than tar archives with a specific file structure. dpkg and rpm both have options to extract the package locally. dpkg -L NAME will show you all the files the installed package has placed on your file system (not generated ones by the code obviously but ones that came with the archive). pip has similar options.

More broadly, and I am sorry if I am wrong here, but what do you expect to glean from reading that code if you don’t bother reading the man page for your package manager?

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

#832

Post by prepend »

marcus_holmes wrote: post #789
prepend wrote: post #783

Earlier quoted context omitted.

> This model of software development is unsustainable. I don’t think this is right. It seems very sustainable as evidenced by 30+ years of sustained OSS development. It seems very sustainable as we live in a time of the best OSS software ever produced with more high quality software than ever produced by ideological volunteers. I’ve seen statements similar to yours and they just seem so at odds with reality.

I don't think the OSS work around GNU, etc, can be directly compared to the "new" model around npm/gems/pip/etc, which has really only been going for a bit over 10 years. I can't put my finger on why they're different, but they definitely feel different. The big question is what happens when a maintainer wants to retire and a successor can't be found? Or (as in this case), when a maintainer gets so annoyed by their u…

The package ecosystem is growing and there’s more good packages each year. 10 years isn’t 30, but it’s still a long time to show success.

That’s there’s only been a few problems like this despite millions of users is a sign of strength.

I hedge by pinning yo specific versions and keeping my own package manager (RStudio) to keep mirrors if the packages I scan. That the packages are open source means they are easier to scan or fork.

If a maintainer stops then the project can be forked. If nobody wants to fork then that probably means no one cares enough. And that’s ok.

Mostly it forces us to be flexible. I don’t think software is a thing but a process or cycle.

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

#833

Post by epmatsw »

bayesian_horse wrote: post #719
ownagefool wrote: post #84

Earlier quoted context omitted.

That's what .lock files do though.

Not sure if that is even enough, at least in NPM the .lock files work on semantic versions, not commits. I'm not sure if NPM enforces you to change the semantic version with each commit. And even if all of that works, you still run head first into the issue once you inevitably upgrade the dependencies.

Yarn at least includes a hash of the tarball in the lockfile, so even if npm’s immutability fails somehow you’ll at least know.

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

#834

Post by naasking »

Gigachad wrote: post #459
staticassertion wrote: post #420

Earlier quoted context omitted.

> 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 ju…

Permissions inside a programs own code seems incredibly difficult without radical change.

It's actually trivially easy once you remove ambient authority, which is the real source of these security problems. Consider how a program could modify your files if it cannot willy-nilly turn any old string into a file handle.

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

#835

Post by knute »

Aeolun wrote: post #827
brundolf wrote: post #383

Earlier quoted context omitted.

Published versions are immutable, you can only submit a new patch with a new version number. It's common for dependencies to be pinned to a minor version (getting patches automatically), however if you use a package-lock.json, as is the default/best-practice, I believe you should be guarded from any surprise patches. You would discover a change like the one in the OP when you manually ran `npm update` on your dev mac…

> I believe you should be guarded from any surprise patches As far as I know, NPM install still thinks it’s a feature that they install new (compatible with package.json, but not with lockfile) versions.

Which is why you only use `npm install` for development, and `npm ci` for production.

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

#836

Post by newaccount74 »

IgorPartola wrote: post #831
newaccount74 wrote: post #821

Earlier quoted context omitted.

> There is nothing inherent in using packages that means you have to blindly trust the code I use about a dozen different package managers and I have no idea how to check the code they download before they install/deploy it. I often check the source on Github if I need to look something up, but I have no idea how I'd go about verifying that the code on Github is the same as whatever the package managers install.

That sounds like a personal problem. .deb and .rpm packages are nothing more than tar archives with a specific file structure. dpkg and rpm both have options to extract the package locally. dpkg -L NAME will show you all the files the installed package has placed on your file system (not generated ones by the code obviously but ones that came with the archive). pip has similar options. More broadly, and I am sorry if…

The point is, if you want people to review the code before they deploy it, it's better to just give them a source file.

Package managers just make it so convenient to use code without ever looking at it.

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

#837

Post by dns_snek »

dane-pgp wrote: post #615
dns_snek wrote: post #436

Earlier quoted context omitted.

Each version of the package comes with its own source code and license. It's your responsibility to audit new package versions before installing them. And that's what the author did, he published a new version. You can blame your tools and package.json for automatically updating, but at that point it's a self-inflicted injury.

I haven't actually checked if the README or description of the package was updated to reflect the new (malicious) behaviour of the code, but even if it was, I think that knowingly exploiting people's trust to stop their software working should be treated as evidence of hacking. It's like if you went to work one day with a spray can hidden in your jacket and started graffitiing the office walls, but justified your act…

> I think that knowingly exploiting people's trust to stop their software working should be treated as evidence of hacking

How so? The license that you accept each time you install or update the library explicitly states:

"IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY [...]"

Use of automation software (npm, yarn) to auto-magically fetch newer versions of your dependencies doesn't absolve you of respecting the terms of the license. Newer versions could have a different license or contain completely different code, there are no guarantees and no contracts.

> It's like if you went to work one day with a spray can hidden in your jacket and started graffitiing the office walls

I don't think that's a good analogy at all. I think this is much closer to the truth:

It's like your boss called you into the office (i.e. explicit software update), gave you a signed waiver that said you couldn't be held liable for anything that you did to the building (i.e. LICENSE) and told you to go crazy (i.e. not auditing the update), so you spray painted the walls and left.

> Would you still blame the victim for their "self-inflicted injury"

No, because professional software developers and end users should be held to a different standard. The fact that you should be auditing your dependencies is well known, precisely because of such scenarios, but people still choose to ignore it because it's inconvenient. This should be the final wake-up call for devs to start pinning and auditing their dependencies.

For the casual end user, replacing functionality of "File > Open" button would be a dick move by the authors, but still within their rights (assuming MIT license).

All in all, developers should be outraged at the state of the NPM ecosystem and their own software development/release practices. He could have easily stolen everyone's AWS access keys and other tokens/secrets if he truly wanted to be malicious.

You can call him an asshole and you'd likely be right, but he was fully within his rights to do what he did.

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

#838

Post by naasking »

Chris2048 wrote: post #825
jopsen wrote: post #750

Earlier quoted context omitted.

If we are willing to admit that repositories like npm are useful, what can be done to mitigate these issues? Is there some tooling we can build?

Maybe limit the capabilities of software e.g. dictate what permissions are reasonable. Maybe require certain "standard libs" for things like console output that limit what can be output. Also, no auto-update of packages.

You don't need to dictate a standard set of permissions, you just need to remove a single very common anti-pattern called "rights amplification".

Why is a program able to concoct a random string that conveys no authority, into a file handle that conveys monstrous authority potentially over an entire operating system, ie. file_open : string -> File.

That's just crazy if you think about it: a program that only has access to a string can amplify its own permissions into access to your passwords file. This anti-pattern is unfortunately quite pervasive, but it's a library design issue that can be tackled in most existing languages by using better object oriented-design: don't use primitive types, use more domain specific types, and don't expose stdlib functions whereby code can convert an object that conveys few permissions into one that conveys more permissions.

This means deeper parts of a program necessarily have fewer permissions, and the top-level/entry point typically has the most permissions. It makes maintenance and auditing easier to boot.

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

#839

Post by heurisko »

newaccount74 wrote: post #821
heurisko wrote: post #762

Earlier quoted context omitted.

> it is recommended prominently in multiple places that they not blindly trust the code and actually inspect it before using it. The friction in this process is intended. There is nothing inherent in using packages that means you have to blindly trust the code, neither does providing a package mean you have to accept any more responsibility over providing a .php file (packages are just .php files with a few metadata…

> There is nothing inherent in using packages that means you have to blindly trust the code I use about a dozen different package managers and I have no idea how to check the code they download before they install/deploy it. I often check the source on Github if I need to look something up, but I have no idea how I'd go about verifying that the code on Github is the same as whatever the package managers install.

In the context of PHP, the package source is put under vendor/ and in my IDE is automatically indexed. It's very easy to view the source code.

You can even experiment with the packages directly, by editing the files in vendor/.

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

#840

Post by slibhb »

Dylan16807 wrote: post #520
slibhb wrote: post #465

Earlier quoted context omitted.

By publishing free, open source software he wasn't "doing his best to live in the system". That would involve exchanging his labor for currency.

> That would involve exchanging his labor for currency. That's the goal. Or at least one goal. But you can't just press a button and do that. Being in charge of and an expert on open source software can be a way get people to buy your labor, but it's much harder than it should be. Instead many companies will demand you work for free, because it's open source! Also trying to do something good for the world shouldn't m…

> Being in charge of and an expert on open source software can be a way get people to buy your labor, but it's much harder than it should be. Instead many companies will demand you work for free, because it's open source!

It's hard to get paid when you decide to give your work away. If only there was some way a person could enter into a contract in order to guarantee payment in exchange for their work. What a radical idea...

Post reply on HN