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

131–138 of 138 posts

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

#131

Post by semi-extrinsic »

jessaustin wrote: post #103
semi-extrinsic wrote: post #40

Earlier quoted context omitted.

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.

Yes, that closing remark is very interesting. It would essentially be formalising what we somehow do manually/instinctively today: "Installing numpy/react/etc.? Yes, everyone I know trusts that, so I do too." "Installing random small non-popular package? I better have a bit of a look at the code first."

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

#132

Post by dps7t »

nailer wrote: post #129
u223344 wrote: post #91

Earlier quoted context omitted.

According to the parent link they've been waiting for npm support to respond for a over a month.

They filed an official dispute 11 hours ago.

Feb 4th. https://github.com/mishoo/UglifyJS2/issues/936#issuecomment-...

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

#133

Post by raesene3 »

semi-extrinsic wrote: post #130
raesene3 wrote: post #104

Earlier quoted context omitted.

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

I completely agree on the first two paragraphs. Wrt. signing: I'm assuming we are talking about PyPI and NPM here. Also I'm assuming the major threat vector for a repository compromise is that (some of) the dev's accounts on some other services (most likely email) are somehow compromised. In which case it's down to that dev's OPSEC practices whether the repository can be compromised using the data from $OTHER_SERVICE…

Ah yes, so the threat model for developer signing is compromise of the repository. So here we're looking at the OpSec of the repository owner (e.g. PyPI, npm, Rubygems etc), and also the risk of deliberate compromise by the repo. owner (for example where a state with authority over the repository compels them to modify a package)

In terms of compromise there's already been the attack on Rubygems in 2013, but in general the thought here is that these repositories are extremely tempting targets for well-funded attackers. A compromise of npm for example would give an attacker direct access to a very wide range of targets.

Combine this with the very limited resources of the repository owners (most are free resources, likely constraining the money available for defence) and you get a realistic risk of attack, which is mitigated by an appropriate use of signing by the developer.

Docker hub has deployed an implementation of the Update Framework to address this, although the interesting point now is whether people actually use it as it's not compulsory...

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

#134

Post by andrewaylett »

STRML wrote: post #96
andrewaylett wrote: post #82

Earlier quoted context omitted.

Take Maven as an example: it's not vulnerable to this attack for several reasons: 1) No install scripts. Fetching a dependency in NPM will execute arbitrary code. Fetching a dependency in Maven doesn't execute any code from the dependency. Obviously when I run my project, I'm expecting to call code in that dependency, so this is a mitigation not a complete fix. But that does lead on to the next point. Corollary: You…

Unfortunately, it's not as simple as disabling `postinstall` hooks. In dev,, especially, the Node process likely runs as the same user as the one who publishes packages. There is nothing stopping the code from spawning `npm` and publishing a malicious project as soon as it is require()d. And of course, you're requiring it at some point, otherwise why would you install it? A better fix to this issue is to require publ…

Rather than 2FA, Maven requiring a GPG signature provides that extra security for me. Neither are infallible -- malware could infect your system sufficiently to intercept your next legitimate authentication.

Also, disabling install hooks in NPM would make things really difficult for packages that rely on native code as they've traditionally been compiled on install. I consider that an anti-pattern, but it's one that's unlikely to be removed any time soon.

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

#135

Post by NathanKP »

jjnoakes wrote: post #97
NathanKP wrote: post #74

Earlier quoted context omitted.

Solution: 1) Pin your packages to a specific version. If you aren't doing this already they you are in for a world of hurt when someone who doesn't know what they are doing releases a breaking package change on a minor version number. 2) Shrinkwrap your packages. Once again if you aren't already doing this then you npm install will probably break about once per three months when someone pushes a bad package to NPM. 3…

You forgot (4): either never upgrade (missing out on security and bug fixes) or audit every update to every package which you are pulling down (which in node could be thousands) I prefer sticking to curated sets of packages with groups of people focused on doing the auditing and security along side my due diligence. I get security updates, bug fixes, far fewer breaking changes, regular updates, reasonable assurance t…

> curated sets of packages with groups of people focused on doing the auditing and security along side my due diligence

How does this differ from how NPM works? For example the set of packages that is utilized by Express is downloaded more than 5 million times per month. There are tons of eyes all over those packages.

Sure if you are installing sketchy packages that have 100 downloads a month you have to do a lot of auditing yourself, but when sticking to the core modules that are used in practically every node project you can benefit from the auditing being done by all the others who use those packages.

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

#136

Post by jrochkind1 »

matt_kantor wrote: post #124
jrochkind1 wrote: post #84

Earlier quoted context omitted.

What do you mean by 'safe'? There is such a tool built-into semver -- it's releasing with a patch or minor version bump! Which means it should be entirely backwards compatible with the previous release. Do you mean something else by 'safe'? I think the issue parent is worried about is if you can't trust the author's declaration of safety.

I think davnn meant a voting mechanism to allow other devs (besides the package's publisher) to vouch for its safety. At least that's how I interpreted "social safety score".

Ah, I see. I guess that might be interesting. I suspect it would have to get very complicated supporting 'chains of trust' and possibly crypto implementation, to avoid gaming by someone who wanted to make their dangerous code look voted "safe" by lots of people.

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

#137

Post by mchahn »

I am always surprised when I hear of developers letting new versions of dependencies go into production. I cannot imagine taking such a chance.

Even if every new version of the total app is tested heavily before production, you lose the inherent stability of shipping the same code that is known stable from the users over time.

Others have said it is important to use new versions of dependencies to get the bug fixes but I don't see that as a good trade-off.

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

#138

Post by jjnoakes »

NathanKP wrote: post #135
jjnoakes wrote: post #97

Earlier quoted context omitted.

You forgot (4): either never upgrade (missing out on security and bug fixes) or audit every update to every package which you are pulling down (which in node could be thousands) I prefer sticking to curated sets of packages with groups of people focused on doing the auditing and security along side my due diligence. I get security updates, bug fixes, far fewer breaking changes, regular updates, reasonable assurance t…

> curated sets of packages with groups of people focused on doing the auditing and security along side my due diligence How does this differ from how NPM works? For example the set of packages that is utilized by Express is downloaded more than 5 million times per month. There are tons of eyes all over those packages. Sure if you are installing sketchy packages that have 100 downloads a month you have to do a lot of…

I don't think there are eyes all over those packages though.
Post reply on HN