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

Vulnerability #319816 – npm fails to restrict the actions of malicious packages

kb.cert.org

Post reply on HN
Print view View original

71–80 of 138 posts

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#71

Post by inglor »

DrJokepu wrote: post #69
inglor wrote: post #57

Earlier quoted context omitted.

When you `npm install` a package by default when other users `npm install` it it will install the most recent patch version - even if it's different from the one you installed. So if you install dependencies through `npm install --save` which is the default and advertized way - you can get completely different code between production and staging. As a library maintainer, patches breaking the library is something that…

I mean, don't use `npm install --save` then. I'm not really sure why people started using it in the first place, it's such a lazy thing to do. Instead, add it to your package.json yourself with the exact specific version you want (none of the ^a.b.c funny business).

When I bootstrap code I npm install --save, I have 10 packages I usually need right off the bat and I don't want to start an investigation every time I do this.

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#72

Post by madeofpalk »

DrJokepu wrote: post #69
inglor wrote: post #57

Earlier quoted context omitted.

When you `npm install` a package by default when other users `npm install` it it will install the most recent patch version - even if it's different from the one you installed. So if you install dependencies through `npm install --save` which is the default and advertized way - you can get completely different code between production and staging. As a library maintainer, patches breaking the library is something that…

I mean, don't use `npm install --save` then. I'm not really sure why people started using it in the first place, it's such a lazy thing to do. Instead, add it to your package.json yourself with the exact specific version you want (none of the ^a.b.c funny business).

or rather, npm install --save-exact :)

then upgrade with npm shrinkwrap

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#73

Post by igl »

DrJokepu wrote: post #69
inglor wrote: post #57

Earlier quoted context omitted.

When you `npm install` a package by default when other users `npm install` it it will install the most recent patch version - even if it's different from the one you installed. So if you install dependencies through `npm install --save` which is the default and advertized way - you can get completely different code between production and staging. As a library maintainer, patches breaking the library is something that…

I mean, don't use `npm install --save` then. I'm not really sure why people started using it in the first place, it's such a lazy thing to do. Instead, add it to your package.json yourself with the exact specific version you want (none of the ^a.b.c funny business).

echo "save-prefix=''" > ~/.npmrc

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#74

Post by NathanKP »

vjeux wrote: post #5
userbinator wrote: post #4

I have a feeling that a lot of other systems also provide "the capability for a self-replicating worm", as that's just the nature of computers in general, and part of why they're so very useful. To me, the fact that this "vulnerability" requires explicit user action, akin to deliberately downloading and running malware, says that it's really a property of all software ecosystems in which people can publish and dissem…

As a developer in the node ecosystem, you run npm install multiple times a day. If one of the dependency you require has been infected, it will look for all the packages you own on npm and will publish a new infected version. Now any time another developer that has one of your packages as dependencies does npm install, it will infect that person again. Once it reaches a package like left-pad that is used by a ton of…

Solution:

1) Pin your packages to a specific version. If you aren't doing this already they you are in for a world of hurt when someone who doesn't know what they are doing releases a breaking package change on a minor version number.

2) Shrinkwrap your packages. Once again if you aren't already doing this then you npm install will probably break about once per three months when someone pushes a bad package to NPM.

3) Publish your NPM packages from an NPM in one vagrant development environment and run your code that installs from NPM in another vagrant development environment. If you have one shared environment then you are going to have other issues of which the small chance of an NPM worm is probably going to be the least of your worries.

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#75

Post by drunkcatsdgaf »

McP wrote: post #66
JdeBP wrote: post #64

Earlier quoted context omitted.

According to https://news.ycombinator.com/item?id=11341142 , in at least one case, now, this is not true.

Except the exact same code was republished, so the point still stands.

This time

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#77

Post by Silhouette »

DrJokepu wrote: post #69
inglor wrote: post #57

Earlier quoted context omitted.

When you `npm install` a package by default when other users `npm install` it it will install the most recent patch version - even if it's different from the one you installed. So if you install dependencies through `npm install --save` which is the default and advertized way - you can get completely different code between production and staging. As a library maintainer, patches breaking the library is something that…

I mean, don't use `npm install --save` then. I'm not really sure why people started using it in the first place, it's such a lazy thing to do. Instead, add it to your package.json yourself with the exact specific version you want (none of the ^a.b.c funny business).

Instead, add it to your package.json yourself with the exact specific version you want

Unfortunately, the same problem then arises for your dependencies. If any of them don't specify exact versions, you are still vulnerable to getting uncontrolled changes.

This is why things like npm shrinkwrap exist, but it's still crazy that NPM's default behaviour is the uncontrolled case.

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#78

Post by Silhouette »

pygy_ wrote: post #68
kibwen wrote: post #65

Earlier quoted context omitted.

I'm not trying to dispute that a problem exists, only that semver is a red herring here. It seems like the problem that you describe doesn't have to do with semver, rather that it has to do with npm lacking something like lockfiles.

It is semver compounded with the "^x.y.z" version requirements for dependencies that NPM uses as a default when a package author `npm install --save` something. When someone else installs that package it will bump y or z if `x > 0`, and z if `x == 0 && y > 0` for all dependencies. You can manually freeze deps to 'x.y.z'. The main problem is the "^" default.

The main problem is the "^" default.

This is true.

A secondary problem is the culture of having so many dependencies, which has been much discussed this past week. Even if you lock everything to a static version for consistency, how many people really know which packages from which sources they are relying on to build their system today? Presumably you trust your direct dependencies, and they in turn trust theirs, and so on, but all it takes is one package five levels deep in the tree where the developer was in a rush and npm install'd something vulnerable or malicious to compromise the entire tree.

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#79

Post by johannes1234321 »

mayank wrote: post #9
paulirish wrote: post #7

Earlier quoted context omitted.

NPM could take a few actions. The original disclosure PDF[1] suggests these: ● Automatically expire login tokens ● Require 2 factor auth for publish operations ● Help users be logged out during install operations vjeux mentioned a few others on HN a few days back[2]: ● pre-install/post-install scripts should require user to accept or refuse. ● make shrinkwrap by default (and fix all the issues with it) so that runnin…

It's definitely a nuanced issue. > ● Automatically expire login tokens I don't see how this helps the issue at hand; a worm could spread very quickly, requiring just a single publish from each freshly infected user. > ● Require 2 factor auth for publish operations This seems very reasonable, and the easiest to implement. It also has the nice effect of being a captcha to the publish operation, which gives it some of t…

> > ● pre-install/post-install scripts should require user to accept or refuse. > > Presumably this would be unnecessary with 2FA for each publish operation.

2FA still doesn't mean you can trust the install script. Not running scripts automatically gives a chance to audit before they run.

And even with 2FA a worm could spread: It could manipulate the local npm installation so whenever you want to upload a package it will modify it during the publishing process giving you a 2nd-factor-request right when you expect it.

The only way to prevent that I can come up quickly is to over a chance to verify the package between signing (which npm doesn't support) and publishing.

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#80

Post by yoklov »

chromakode wrote: post #27

In development, you should separate your npm publish credentials from your dev execution environment. Use some kind of sandbox where you `npm install` -- a VM is best. In production, you should review the packages in your dependency tree and ensure that the exact version you reviewed is what you deploy. To that end, you should shrinkwrap your dependencies. Vendoring works well too. Shameless plug: for additional stri…

Do people do this? It sounds unmanageable, especially if you publish packages depending on other packages.
Post reply on HN