Vulnerability #319816 – npm fails to restrict the actions of malicious packages
1–10 of 138 posts
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#2And no intention from NPM to fix (according to the article)
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#3And no intention from NPM to fix (according to the article)
What solution can we propose?
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#4I 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 disseminate freely.
In that respect, it's nice to see a "this is as intended" response instead of the typical direction of coming up with a set of more draconian policies and processes merely to protect users from themselves.
But given what "security research" these days seems to involve, I can almost imagine in the future: "Vulnerability #1048576 - computer allows users to perform potentially malicious actions."
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#5I 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 libraries, it will instantly infect hundreds of thousands of developers.
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#6And no intention from NPM to fix (according to the article)
What solution can we propose?
The article suggests this:
>
>As a user who owns modules you should not stay logged into npm. (Easily enough, npm logout and npmlogin)
>Use npm shrinkwrap to lock down your dependencies
>Use npminstall someModule --ignore-scripts
>
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#7And no intention from NPM to fix (according to the article)
What solution can we propose?
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 running npm install doesn't use different versions when used over time.
● make updating a version an explicit decision via npm upgrade
[1] https://www.kb.cert.org/CERT_WEB/services/vul-notes.nsf/6eac... [2] https://news.ycombinator.com/item?id=11341145
In the meantime, users may want to consider one of the following:
npm config set ignore-scripts true
npm logoutRe: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#8Unless I'm not understanding this correctly, every package manager is vulnerable to this attack (along with many others). I'm not sure why someone bothered to write this down and make an official "disclosure". Maybe someone more knowledgeable can explain?
I mean really the idea is just that if someone got somebody else's password, they could use it to trick other people into installing a program. Even email has this problem. So really the only thing NPM could be accused of here is not doing more to make publishing secure (like using two-factor authentication).
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#9Earlier quoted context omitted.
What solution can we propose?
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 the gravitas it deserves in an open ecosystem like npm.
> ● Help users be logged out during install operations
This may break far more packages than might be considered acceptable.
> ● pre-install/post-install scripts should require user to accept or refuse.
Presumably this would be unnecessary with 2FA for each publish operation.
> ● make shrinkwrap by default (and fix all the issues with it) so that running npm install doesn't use different versions when used over time.
Doesn't do much to address the issue at hand. A static dependency tree doesn't mean benevolent dependencies.
> ● make updating a version an explicit decision via npm upgrade
Same issues as shrinkwrap.
Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages
#10Unless I'm not understanding this correctly, every package manager is vulnerable to this attack (along with many others). I'm not sure why someone bothered to write this down and make an official "disclosure". Maybe someone more knowledgeable can explain? I mean really the idea is just that if someone got somebody else's password, they could use it to trick other people into installing a program. Even email has this…
Well, isn't proper authentication a solution in and of itself? Using keys with pass phrases or requiring sudo to publish would theoretically mitigate this issue.