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

21–30 of 138 posts

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

#21

Post by wycats »

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…

>> ● 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.

I agree, especially since Google Authenticator makes this pretty easy to implement.

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

#22

Post by badminton1 »

wycats wrote: post #19
blaisio wrote: post #8

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

The note offers this workaround for npm: "Use npm shrinkwrap to lock down your dependencies", which will prevent the worm from spreading purely because of an install of a checked out app. Any application package manager with a lockfile-based-workflow (like Bundler, Cocoapods, Cargo, etc.) would at least have this mitigation as a default part of the workflow.

shrinkwrap might work for a bit. but if you regenerate the file you will run into the same issue.

a way to protect you 100% against the problem is to define your dependency as a link to a specific commit or tarball.

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

#24

Post by chromakode »

blaisio wrote: post #8

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

IMHO the primary issue at play here is that publishing to the npm repository doesn't currently require proof of user presence, which enables a worm to propagate to other packages automatically.

The npm team is working on 2fac (https://twitter.com/seldo/status/713623991349411840) which will be an adequate solution to this issue.

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

#25

Post by chromakode »

spankalee wrote: post #15

Automatically running pre and post scripts is absolutely insane.

Once you've installed a malicious package that you intend to use, you've already lost. Even without a pre/post install script, it'll be executed eventually. The underlying problem is managing risk of the packages you install.

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

#26

Post by dclowd9901 »

badminton1 wrote: post #22
wycats wrote: post #19

Earlier quoted context omitted.

The note offers this workaround for npm: "Use npm shrinkwrap to lock down your dependencies", which will prevent the worm from spreading purely because of an install of a checked out app. Any application package manager with a lockfile-based-workflow (like Bundler, Cocoapods, Cargo, etc.) would at least have this mitigation as a default part of the workflow.

shrinkwrap might work for a bit. but if you regenerate the file you will run into the same issue. a way to protect you 100% against the problem is to define your dependency as a link to a specific commit or tarball.

Or a specific version since they can't be written to twice in the npm repo.

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

#27

Post by chromakode »

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 strictness in your shrinkwrap, you can use https://github.com/chromakode/exactly to store content hashes.

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

#29

Post by dclowd9901 »

spankalee wrote: post #15

Automatically running pre and post scripts is absolutely insane.

Again, they are run only when you run those commands explicitly on the packages in question. The only reason you would do that on code that wasn't yours was is if you were developing on a forked module, which should be trustworthy, or you've at least read it's code.

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

#30

Post by derefr »

wycats wrote: post #20
spankalee wrote: post #15

Automatically running pre and post scripts is absolutely insane.

All package managers (that I know of) for dynamic languages offer a mechanism for compiling native code for packages that include bindings to C libraries. That mechanism could easily be used to achieve the same goal, even if there was no explicit "post-script" mechanism.

Debian solved this particular problem a long time ago, with pbuilder(1): packages that are installed "from source" simply get compiled in a chroot. Strangely, nobody has ever copied the idea.

The modern hipster-language equivalent would probably be to make the package manager depend on the presence of Docker/rkt/systemd, and use it to pull down a dev-env container and build the native bindings in that.

Post reply on HN