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

111–120 of 138 posts

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

#111

Post by nickpsecurity »

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…

Here's the definitive work on the subject from the past:

http://www.dwheeler.com/essays/scm-security.html

He has lots of nice links, too. Hope you can factor some of it into your talks to get it to mainstream audience. I've saved the vid to check it out later. Will be interesting to see an experienced perspective with the modern tooling.

However, I admit I've always thought updating Shapiro's OpenCM or Aegis to distributed style with plugins for modern tooling gets us 90+% percent of the way. Without the problems of 90+% of build and package mgmt systems. ;)

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

#112

Post by pfooti »

I feel like, with the left-pad fiasco, the node dev world (and the broader programmer community) is rediscovering the web of trust that makes open source feasible.

I mean, if I distributed a library through some other package manager system, like a .jar file or some code that you install via homebrew, pip, or ./configure.sh && make, I can embed malicious code in the source somewhere. Maybe not all automated package managers are quite as vulnerable to install hooks, but all open source code is vulnerable to trust attacks, at runtime if nowhere else. I ultimately trust the process that gives me nginx enough to let it serve up my code, hoping there's not a backdoor somewhere that is shoving environment variables (and therefore API keys) out the window to a hacker.

You can't assume people are going to review every line of source before they link against a library. You can't assume people aren't going to click that link that looks like a download link on a sourceforge page but is, in fact, a crapware link. People make mistakes all the time.

So, yeah, there's probably room to make npm a little more robust and difficult to specifically target as a vector. But thousands of developers are still going to be writing sass, and using node-sass to build that, which needs to download, compile and execute a binary on the devbox. Making the installation process of libsass take an extra step or two is great and all (and annoying, and probably likely to degrade windows node development most of all, since windows libraries are harder to put in a "standard" place if you're a non-windows dev writing a node library), but people are still going to be running libsass binaries on their local machine without auditing it, trusting that the developers there have good opsec and review everything well.

On the other hand, all this publicity means someone's bound to actually try and build stuff that exploits trust here, either wormlike or just executing an rm -rf in an install hook. So, my trust levels are lowered and my productivity impaired because I'll be auditing more closely all the updates to existing plugins I'm using. Win?

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

#113

Post by nickpsecurity »

Here's a reference work with links to key papers on build system security for anyone trying to improve them:

http://www.dwheeler.com/essays/scm-security.html

Dig into archive.org for Shapiro's OpenCM while you're at it as it had a lot of nice properties. Aegis seemed to as well. Pulling good traits from Wheeler's survey into modern ones would be a good idea. Also, one can re-develop OpenCM, Aegis, etc to have modern features like plugins for common languages/apps or DVCS capabilities.

SCM security techniques date back to 80's-early 90's. No excuse for today's solutions to still lack the basics.

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

#114

Post by jdavis703 »

TheCoreh wrote: post #83
pygy_ wrote: post #68

Earlier quoted context omitted.

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.

Even if you manually freeze deps to 'x.y.z', the deps of your deps might still be specified with '^'. Ideally you'd shrinkwrap, and commit node_modules to your repo. (In case packages get deleted)

What's the point of shrinkwrap if you're commiting node_modules? And also why not use a package manager like RPM, Debian, etc so you don't bloat your Git history? (Genuine questions, I know many advocate what you're saying).

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

#115

Post by digi_owl »

ambrop7 wrote: post #46
derefr wrote: post #30

Earlier quoted context omitted.

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.

Nix/NixOS - everything is build not only in a chroot, but also in various namespaces. Of course that doesn't help if you actually use a package (directly or indirectly) hence executing it outside of the build chroot.

Similar with Gobolinux, iirc. With a union mount on top to redirect the files written during the install step.

Afterwards the sub-directory in /Programs can basically be turned into an archive for future installs.

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

#116

Post by chromakode »

jdavis703 wrote: post #114
TheCoreh wrote: post #83

Earlier quoted context omitted.

Even if you manually freeze deps to 'x.y.z', the deps of your deps might still be specified with '^'. Ideally you'd shrinkwrap, and commit node_modules to your repo. (In case packages get deleted)

What's the point of shrinkwrap if you're commiting node_modules? And also why not use a package manager like RPM, Debian, etc so you don't bloat your Git history? (Genuine questions, I know many advocate what you're saying).

Vendoring by storing node_modules works great. It's not necessary to shrinkwrap in that case -- all the same data is derived from the node_modules directory tree. For production, I often use a separate git repo for storing node_modules, referenced as a submodule of the code repo. This has two advantages:

* You retain history for your full dependency tree separately from your codebase.

* Every commit of your code repo exactly specifies the contents of its dependency tree, since the submodule references your deps repo by commit hash.

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

#117

Post by chromakode »

pfooti wrote: post #112

I feel like, with the left-pad fiasco, the node dev world (and the broader programmer community) is rediscovering the web of trust that makes open source feasible. I mean, if I distributed a library through some other package manager system, like a .jar file or some code that you install via homebrew, pip, or ./configure.sh && make, I can embed malicious code in the source somewhere. Maybe not all automated package m…

I've been tinkering on one approach to trustworthy OSS ecosystem at https://github.com/chromakode/signet.

The OSS world has grown precipitously in the era of GitHub/npm/etc, and the trust model hasn't caught up. It's not tenable to maintain a GPG keychain for a nested tree of 100 dependencies. Neither is it advisable to keep deferring this problem. We need to come up with a solution for tracking reputation and trustworthy dependencies at this new scale. It's not simply a problem that package repositories like npm can solve for us -- the scope of this problem is human, and an ideal solution will work for both users and developers, and apply to source distributions and multiple package repositories. One of the few silver linings of the events of the last week is that more people are aware of and pondering these issues. I hope we'll see some more discussion and experimentation in this space!

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

#118

Post by Gracana »

chromakode wrote: post #117
pfooti wrote: post #112

I feel like, with the left-pad fiasco, the node dev world (and the broader programmer community) is rediscovering the web of trust that makes open source feasible. I mean, if I distributed a library through some other package manager system, like a .jar file or some code that you install via homebrew, pip, or ./configure.sh && make, I can embed malicious code in the source somewhere. Maybe not all automated package m…

I've been tinkering on one approach to trustworthy OSS ecosystem at https://github.com/chromakode/signet . The OSS world has grown precipitously in the era of GitHub/npm/etc, and the trust model hasn't caught up. It's not tenable to maintain a GPG keychain for a nested tree of 100 dependencies. Neither is it advisable to keep deferring this problem. We need to come up with a solution for tracking reputation and trust…

I like the general idea of this and I think it would be interesting to see how various software hubs could integrate it.

An easy thing you could do right now is to put an attestation directory right into your git repo. Then write up your comments (maybe in a file format similar to what you're doing with signet) and do a signed commit into that directory.

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

#119

Post by mayank »

nawitus wrote: post #100
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…

"This may break far more packages than might be considered acceptable." Can you elaborate?

I thought about this a bit more, and I can't think of a single legitimate reason to be logged into npm during a third-party package install. Of course, that doesn't mean packages won't break if anyone was depending on this behavior, but you're right -- perhaps those packages should break.

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

#120

Post by acemarke »

chromakode wrote: post #116
jdavis703 wrote: post #114

Earlier quoted context omitted.

What's the point of shrinkwrap if you're commiting node_modules? And also why not use a package manager like RPM, Debian, etc so you don't bloat your Git history? (Genuine questions, I know many advocate what you're saying).

Vendoring by storing node_modules works great. It's not necessary to shrinkwrap in that case -- all the same data is derived from the node_modules directory tree. For production, I often use a separate git repo for storing node_modules, referenced as a submodule of the code repo. This has two advantages: * You retain history for your full dependency tree separately from your codebase. * Every commit of your code repo…

Re-re-posting a comment I've made in a few threads now, because I feel this needs to get more awareness:

I'm still learning and prototyping my first JS/NPM/React project, but https://github.com/JamieMason/shrinkpack seems to me like it solves _most_ of the issues involved here. It pulls down all the tarballs, and updates the npm-shrinkwrap.json to point to those instead. That way you check in a much smaller "node_shrinkwrap" folder of a few hundred tarballs and 15-20MB, rather than a node_modules folder of 30K files and 150MB and a bunch of platform-specific build outputs.

Still doesn't solve the issue of installing new/updated dependencies that might actually require pulling in something that vanished, but at least once you've done an install and run "shrinkpack", you've got everything you need to rebuild right there.

Post reply on HN