9 ms·

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 w

• ghayes 11y ago
  Well, isn't proper authentication a solution in and of itself? Using keys with pass phrases or requiring sudo to publish would theoretically mitigate this issue.
  • minitech 11y ago
    No, because it can just sit in the background and wait until you type your passphrase at some point. As soon as you run malicious code, it’s all over; no workarounds. It would be nice if npm didn’t run arbitrary install scripts by default…
• BenjaminCoe 11y ago
  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-scripts-vulnerability http://blog.npmjs.org/post/141702881055/package-install-scri...
  • raesene3 11y ago
    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.
    • semi-extrinsic 11y ago
      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 https://bugzilla.mozilla.org/show_bug.cgi?id=1227867#c2 [2] https://forums.zotero.org/discussion/28847/zotero-addon-is-no-longer-available-at-mozillas-addons/ https://forums.zotero.org/discussion/28847/zotero-addon-is-n...
      • raesene3 11y ago
        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)
        • semi-extrinsic 11y ago
          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)?
• deleted 11y ago
  [deleted]
• wycats 11y ago
  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.
  • partycoder 11y ago
    shrinkwrap might work for a bit. but if you regenerate the file you will run into the same issue. a way to protect you 100% against the problem is to define your dependency as a link to a specific commit or tarball.
    • dclowd9901 11y ago
      Or a specific version since they can't be written to twice in the npm repo.
      • JdeBP 11y ago
        According to https://news.ycombinator.com/item?id=11341142 https://news.ycombinator.com/item?id=11341142 , in at least one case, now, this is not true.
        • McP 11y ago
          Except the exact same code was republished, so the point still stands.
          • drunkcatsdgaf 11y ago
            This time
            • deleted 11y ago
              [deleted]
• chromakode 11y ago
  IMHO the primary issue at play here is that publishing to the npm repository doesn't currently require proof of user presence, which enables a worm to propagate to other packages automatically. The npm team is working on 2fac (https://twitter.com/seldo/status/713623991349411840 https://twitter.com/seldo/status/713623991349411840) which will be an adequate solution to this issue.
• binarycrusader 11y ago
  Not every package manager, for example the Solaris 11 package manager explicitly does not support install time scripting for this reason among many others: https://blogs.oracle.com/sch/entry/pkg_1_a_no_scripting https://blogs.oracle.com/sch/entry/pkg_1_a_no_scripting
• raesene3 11y ago
  One of the problems is that npm (and others) put their credentials or some form of API token into dotfiles in the developers home directory, meaning that if you can execute code as the user (via social engineering or malware) you can push new packages. In some cases it's even accepted practice to put the actual username/password in the clear in a dotfile, which means anyone who can even read a file from the users home directory, can gain persistent access to push packages as them...
• vbezhenar 11y ago
  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 better solutions.
  • pfooti 11y ago
    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.
• deleted 11y ago
  [deleted]
• andrewaylett 11y ago
  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 have to change the code in my project to spread the worm, not just add a new dependency, otherwise your worm code won't get executed. This is probably a bit more tricky to get right. 2a) Code deployed internally from CI servers, not local machines. It's got to be code-reviewed before it gets pushed to my employer's package repository. 2b) Code needs to be signed before being uploaded to Maven Central. I'm not going to start typing my GPG key into random unexpected prompts. Malicious code is still a possibility, but the scope for a worm is much less.
  • STRML 11y ago
    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 publishers to enter a two-factor token, to email them to confirm publishing, or the like. Yeah, it makes everyone a bit uneasy with how much trust is involved in the ecosystem. Is there a better solution?
    • andrewaylett 11y ago
      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.
• mortehu 11y ago
  I would say Debian is not vulnerable (to step 6), even for users of the rolling "unstable" release, since maintainers need to sign package uploads with their PGP key, which is usually protected by a separate password.