RC npm: install scripts are common attack vectors

[mlieberman85]

It should probably be noted in the doc that install scripts are often dangerous as they can allow for the running of arbitrary code at installation time. This has been used in the past to try and steal credentials (mostly related to crypto wallets and the like.)

Should suggest in most cases applying: npm --ignore-scripts when possible.

[ljharb]

That suggestion is complicated, because it breaks a lot of valid use cases.

[mlieberman85]

Well, when possible. There are valid use cases but I also think in general running unknown arbitrary scripts as part of installation should be discouraged, unless there's a way to sandbox it.

I would be also curious to know if there's any effort from npm side to support certain common use cases just in a safer way. Are there any specific use cases that come to mind where you would 100% want to run arbitrary scripts as part of installation?

[ljharb]

I don't think anyone would dispute that install scripts "should be" discouraged.

That, however, is irrelevant - they're currently the only way to accomplish a bunch of valid use cases. As such, until there's a better alternative for these, it would be harmful to recommend ignoring scripts.

Valid use cases include "compile something after install", "download an artifact tailored to the system on install", etc.

[lirantal]

I'm tending towards security by default here and with recommending the use of various methods in which --ignore-scripts comes into play, whether that's via command line, or through the .npmrc config.

[laurentsimon]

So we all agree that scripts are a potential source of attacks.

Given that a lot of things will be breaking if users use the --ignore-scripts, how about the following changes:

1. In the "Dependency management > Intake" section, we could suggest doing a code review, and explicitly mention the scripts as part of the "code". (most users won't code review, but if they do they will take a look at the script as well)

2. We can add a note in the same section that there exists a --ignore-scripts for users who want to impose a policy on scripts; warn that because there are genuine use cases it is likely to break; and conclude that for this reason so we do not recommend it unless users verify themselves that none of their dependencies need it.

Wdut?

[lirantal]

Do we have any data as supporting evidence for the statement that "given that a lot of things will be breaking if users use --ignore-scripts" ?

[laurentsimon]

I personally don't; but I suppose listing all the packages that use scripts (possibly with a combination of dependency graph desp.dev) could provide a more scientific answer.

@oliverchang @calebbrown is this data we could pull out from the package analysis project?

[ljharb]

Anything that compiles on install, or downloads assets on install, won't work when ignoring scripts - which includes electron, sass, and a bunch of others.

[laurentsimon]

@lirantal is this convincing enough? Note that we're not ruling out, we're just saying developers may use it but at their own risk. If there's a better way to express it, please let us know.

[lirantal]

Just a small note that this and #20 are very similar so maybe we consolidate this discussion on one of them. @laurentsimon with regards to the above, if we're saying developers may use at their own risk then why even both here with best practices at all? please see my input here

As to the above examples:

1. Electron isn't something that end users install regularly, is it?
2. node-sass I accept and am familiar with and I am happy to see it is showing a declining downloads trend

[ljharb]

“Best practices” doesn’t mean “be as paranoid as possible”, it means “have the best balance between security and usability as possible”. Many potential security measures don’t meet that bar - including ignore-scripts.

[mlieberman85]

So, I would argue it's not paranoia given that a common attack is to use pre/post scripts to run malicious code like stealing crypto wallet keys. Certain other languages don't allow arbitrary pre/post scripts or have built in mechanisms for the package manager to sandbox the installation.

I haven't been around npm much in the past several years, but if we can't suggest ignore scripts, are there suggestions we can make around best practices for sandboxing or avoiding the common attacks?

[ljharb]

"paranoia" doesn't necessarily imply "unjustified" :-)

That's the problem. There is nothing that can be done short of ignoring all scripts, and there are no alternatives for package authors to avoid using scripts for the many relevant use cases.

Until npm provides alternatives - or more granular protection mechanisms - the status quo (virtually nobody ignores scripts, and those who do tend to run into problems) remains unchanged.

[jeffmendoza]

Closing with same reasoning as #20

[naugtur]

@ljharb issues with --ignore-scripts have been solved by @lavamoat/allow-scripts

It covers:

• allowing selected scripts
• setting up the repository and adding the flag
• avoiding running an install script from a package that spoofed its name (eg. A bundled package that calls itself bcrypt won't get run if you allowed the real bcrypt)
• stopping the installation early if the ignore-scripts flag was somehow accidentally removed or forgotten

No functionality depending on install scripts is broken.

There is no other way to defend against well crafted malicious packages using this technique. And they're becoming more and more common.

Full talk on this topic exactly: https://m.youtube.com/watch?v=y2p1e7UmGYY

[ljharb]

Replied in #20.