Live data from Hacker News

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

kb.cert.org

11–20 of 138 posts

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

#11
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…

Similar problems exist in most package management systems. registries that have a manual review process mitigate this danger, but there's still always a risk of malicious code getting into the world.

Having said this, we'd like to make exploits such as those discussed in #319816 as difficult as possible. We're exploring supporting new authentication strategies: such as 2-factor authentication, SAML, and asymmetric key based authentication (some of these features are already available in our Enterprise product, but haven't made it to the public registry yet). npm's official response has more details on this subject:

http://blog.npmjs.org/post/141702881055/package-install-scri...

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

#12
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…

[deleted]

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

#17

Automatically running pre and post scripts is absolutely insane.

Yes, with that you don't even need to "socially fool the package owner". You can use common misspelling for famous packages. It gets you very far.

For example "lowdash" instead of lodash.

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

#19
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.

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

#20

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.

Post reply on HN