Vulnerability #319816 – npm fails to restrict the actions of malicious packages • Hacker News Board

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

#101

Post by semi-extrinsic » Sat, Mar 26, 2016, 3:08 PM UTC

raesene3 wrote: post #50

semi-extrinsic wrote: post #49

Earlier quoted context omitted.

Firefox has automated "malware checking" for extensions, the Mozilla AMO Validator, and it's been basically torn to pieces by the community for being not actually secure [1] plus a major hassle for developers [2], to the point that large extensions with hundreds of thousands of users have stopped using the official Firefox extensions repository. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1227867#c2 [2] https://…

Yep it's a really nasty problem for any package manager that operates at scale. The problem is that without any centralized validation of packages, it leaves checking to each developer who uses the libraries and obviously from an effort standpoint that just makes it worse (i.e. if it's hard for the repo owner to do validation it's hard x number_of_users for it to be done by end users)

The problem is basically how the centralized validation is supposed to work. For e.g. the Linux kernel, it's doable because all code in the kernel must (almost by definition) interact with some other part of the kernel. Thus someone else than the code owner, being responsible for those other parts of the kernel, can be tasked with signing off on the new code being good and non-malicious.

But for NPM or PyPI, where anyone can upload anything, how's that supposed to work? It's perfectly fine for someone to put a package called "removeallfiles" on PyPI which executes "sudo rm -rf /". This isn't (by itself) malicious code. The same code, but obfuscated and put in the package name "isarray", is perhaps obviously malicious. But what about something in the middle, e.g. some form of practical joke package? What central authority decides what is allowed and what is not on PyPI?

Signing is a tangential issue. As long as you're trusting the dev who uploaded the code, what difference does it make whether they used password or public key auth (effectively)?

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

#102

Post by DrJokepu » Sat, Mar 26, 2016, 3:19 PM UTC

Silhouette wrote: post #77

DrJokepu wrote: post #69

Earlier quoted context omitted.

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.

Yes, libraries should specify exact versions as well, it's insane that they don't.

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

#103

Post by jessaustin » Sat, Mar 26, 2016, 3:22 PM UTC

semi-extrinsic wrote: post #40

raesene3 wrote: post #38

Kind of amusing that this is considered to need a new vuln. report, I kind of assumed it was common knowledge. Most of the programming language package repositories (e.g. npm, rubygems, PyPi, NuGet) have this kind of installation process and limited/no checks for malicious content. Also as there's no consistent use of package signing by the developer (it's either unsupported or not very used) there is also a risk of…

A very insightful look at package signing, and why it wouldn't actually improve security for PyPI, by Python packaging guru Donald Stufft: https://caremad.io/2013/07/packaging-signing-not-holy-grail/

What a great link: topical and well-reasoned! The concluding sentence is interesting: "My biggest hope is that we’ll get a solution where the end user has the relationship with the source of trust and not the package author." If one runs one's own npm registry and audits everything that goes into it, one can have that already with npm.

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

#104

Post by raesene3 » Sat, Mar 26, 2016, 3:41 PM UTC

semi-extrinsic wrote: post #101

raesene3 wrote: post #50

Earlier quoted context omitted.

Yep it's a really nasty problem for any package manager that operates at scale. The problem is that without any centralized validation of packages, it leaves checking to each developer who uses the libraries and obviously from an effort standpoint that just makes it worse (i.e. if it's hard for the repo owner to do validation it's hard x number_of_users for it to be done by end users)

The problem is basically how the centralized validation is supposed to work. For e.g. the Linux kernel, it's doable because all code in the kernel must (almost by definition) interact with some other part of the kernel. Thus someone else than the code owner, being responsible for those other parts of the kernel, can be tasked with signing off on the new code being good and non-malicious. But for NPM or PyPI, where an…

Well if there's no central validation, that leaves all individual users to validate packages before use (which is a huge amount of work)...

The problem is that companies are using these packages as though they are trusted (i.e. not validating them when using them), and that's part of the value proposition in the first place (i.e. it's easier to use this package than write it myself), but it's missing the cost of validation.

On signing I'm not sure we're talking about the same thing. I'm referring to developers cryptographically signing packages before pushing to the repository, with a key that the end-user can validate. the idea is to protect against a comrpomise of the repository. There's a good discussion of the risks and potential solutions on The update framework's site (https://theupdateframework.github.io/)

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

#105

Post by raesene3 » Sat, Mar 26, 2016, 3:43 PM UTC

driverdan wrote: post #85

raesene3 wrote: post #37

Earlier quoted context omitted.

Unfortunately I don't think that many/any of the Programming language package repositories have manual review processes, or even automated checking for things like known malware... Linux package managers are a different story of course.

I don't think this is unfortunate at all. I shouldn't have to wait for someone to review my code before publishing an important bugfix. This is the primary thing that drove me away from mobile apps.

On the flip-side how is someone who's using a package from one of these repository meant to validate that it's secure and non-malicious?

without central validation, each user would have to do it, and that's frankly impractical...

The alternative is that no-one actually does the validation and runs the risk of insecure or malicious packages. To me, that's totally fine as long as they're doing it knowingly, however I'd suggest that most companies making use of NPM, PyPI, Rubygems etc are not doing it knowingly...

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

#106

Post by nevir » Sat, Mar 26, 2016, 3:50 PM UTC

kibwen wrote: post #34

> npm encourages the use of semver, or semantic > versioning. With semver, dependencies are not locked to > a certain version by default. For any dependency of a > package, the dependency author can push a new version of > the package. I don't see how this has anything to do with semver. Semver doesn't say anything about not locking dependencies to a certain version (i.e., locking to a specific version is totally leg…

It's poorly worded. The real problem is that _by default_ npm doesn't pin you to an exact version of a dependency.

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

#107

Post by pfooti » Sat, Mar 26, 2016, 3:55 PM UTC

vbezhenar wrote: post #54

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…

If I use maven, dependencies are plain JAR files. Adding dependency doesn't do anything but simple file manipulations. To affect build process, maven uses distinct kind of dependency called plugins. Actually I'm surprised that npm uses some kind of scripts. All I want is to download some JS files. Why is there any scripts at all? I guess it's needed for native compilation, but it's a lazy solution, there could be bet…

There are a surprising number of npm packages that provide a wrapper around a native library to expose bindings to node devs. I use node-sass on the dev side and mmmagic on the production side, both of which require the presence of binaries.

I understand the danger inherent in this system, and actually do keep an eye on dependencies I require. All that said, it's certainly a lot easier to have npm install handle fetching and building native libraries than it is to figure out a way to manually get those libraries attached to the node package (wait, did I install that in /opt, /usr/local, etc etc).

Ultimately, I'm downloading code someone else wrote and executing it. Yes, post- and pre-install hooks are low hanging fruit for malicious exploitation, but so is installing any large library, you can just as easily put Bad Code in a library you distribute for any other language and wait for someone to run it. The difference here is that there's an exploit possible at install time, rather than runtime.

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

#108

Post by jonahx » Sat, Mar 26, 2016, 3:56 PM UTC

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.

what is the recommended way to globally change that default?

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

#109

Post by pfooti » Sat, Mar 26, 2016, 4:02 PM UTC

johannes1234321 wrote: post #79

mayank wrote: post #9

Earlier quoted context omitted.

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…

While I agree that giving people a chance to disable install scripts in order to audit them before / after running is a good idea, I also think it's somewhat optimistic of you to think that this would actually help.

There's plenty of npm packages that release updates weekly. I may not update them every time (I tend to wait until I see a need), but the rate of update is high enough that most people would just blindly click through after the fiftieth time they installed that package.

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

#110

Post by JdeBP » Sat, Mar 26, 2016, 4:12 PM UTC

joshribakoff wrote: post #92

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…

> you can get completely different code between production and staging. That's not NPM's fault, its the fault of the way you deploy code. Even if you locked down a version, git is mutable so someone could change their code. That's why I "rsync" the code to production, so I know its the same as development.

It's also why one wag suggested using Twitter (which "doesn't have an edit button") as a repository:

* https://gist.github.com/rauchg/5b032c2c2166e4e36713