1. 38
  1.  

  2. 14

    For what it’s worth: Any package manager with a post/pre install process has the same exact issue.

    1. 12

      I wouldn’t say exactly. Part of the problem is allowing unvetted randos to publish to the repository, but that’s not a necessary part of package manager design.

      Whenever I set up a new OpenBSD system, I run “pkg_add chrome” which always fails, because the package is actually called chromium (although the binary in the package is called chrome, hence the confusion). It would probably be bad for somebody to come along and squat on the chrome name, but I don’t worry about this.

      1. 6

        Yep, installing a package from an unvetted rando would be about as dumb as installing a CA root certificate from an unvetted rando.

        1. -2

          Part of the problem is allowing unvetted randos to publish to the repository,

          Even if you vet every publisher and vet every publish, someone can still find a MITM weakness and then have libraries post-install hacks.

          1. 3

            A MITM weakness in what?

            1. 2

              In the package manager.

              1. 10

                I would recommend a package manager without such obvious weaknesses.

                1. 0

                  Oh, of course, why didn’t I think of that?

                  EDIT: I honestly can’t believe people on lobster are uploading this person’s troll response.

                  1. [Comment removed by author]

                    1. -1

                      That’s a very generous interpretation, but even then MITM is just one of many surfaces to protect.

                      1. 5

                        Generous? The topic of the subthread was MITM attacks and tedu said “such obvious weaknesses”. TLS and signatures are two of the most well-known defenses against MITM attacks. Seems pretty clear-cut to me.

                    2. 6

                      Too much time spent using npm? It’s certainly possible for a package manager that solves these problems to exist, because such package managers do exist. Debian has been around for how long? When was the last time a typo squatting deb had to recalled?

                      1. -1

                        I was being completely sarcastic. There are no package managers that are immune to security issues and to suggest something so silly is really trolly dude.

                        Here’s how to know if your package manager is vulnerable to this situation:

                        1. Does your package manager have a pre/post-install process that runs in userland?
                        2. Is your package manager written by a human?

                        If you checked both of these boxes you now have a chance to encounter this exact issue.

                        1. 7

                          And yet some package managers seem to have more of this exact issue than others.

                          1. -3

                            As we all know what security is really concerned with is known issues published by users.

                          2. 2

                            There are no package managers that are immune to security issues

                            I don’t think the claim was immunity to security issues. The claim was that there are package managers resistant to phishing and homograph attacks.

                2. 1

                  A significant mitigation is often reasonable, particularly when a total solution isn’t readily available. In this case, I would argue that there is literally nothing that can stop a determined enough individual with the right skills / resources / access from using the package manager against an adversary. But if we can make it more difficult, or just more of a pain, then we’ll still have improved the situation.

              2. 8

                Yup, remember when this happened? https://gist.github.com/titanous/3e4829f79dbd1be11295

                1. 3

                  Oh wow yes! Haha! I also remember the (short lived) reaction https://tonyarcieri.com/lets-figure-out-a-way-to-start-signing-rubygems once people realized they could be post-installing really unknown code.

                  1. 2

                    I wouldn’t know how signing would have helped there.

                    1. 1

                      Cool, wasn’t saying it would have.

                      1. 1

                        Why not? If they stored their private key elsewhere (ie, not on rubygems.org) and the package manager automatically checks signatures, how would this attack have succeeded?

                  2. 4

                    This is interesting, because it is one of the numerous protections Nix and packaging software with Nix protects against.

                    1. 0

                      As posted elsewhere:

                      1. Does your package manager have a pre/post-install process that runs in userland?
                      2. Is your package manager written by a human?

                      If you checked both of these boxes you now have a chance to encounter this exact issue.

                      Nix may be special in that it also has the concept of self contained processing? This is a rather large ask of normal package managers. Can you provide more insight?

                      1. 4

                        #1 is effectively a “no”. The hooks are run, but in a sandbox without access to the general application, operating environment, or the network.

                        EDIT: of course, the install time problem also impacts any package manager where you run the code it manages, assuming the running code ever interacts with sensitive internal data or environment. However, Nix very nicely protects against install-time trouble-makers.

                        1. 1

                          No network or operating environment is a killer. I get that it means nix packages are secure, but quite a few popular npm packages determine what OS you’re on and then download binaries (instead of building from source).

                          1. 3

                            I don’t know the details for NPM specifically, but we’re quite comfortable patching around issues like that, and indeed have done so many times. Sometimes working with the tool we’re dealing with, sometimes working around the tool :) For example pre-fetching what it is looking for and happening to put it where npm will look for it. Sometimes just patching the source of the package, if that is what it takes.

                            1. 1

                              You change nix based on the needs of the library author? Even if npm could create a sandbox for post install and it worked with what they already had, there are so many packages and authors that I doubt it would be feasible.

                              1. 2

                                No, we don’t change nix, we patch the software being packaged by nix.

                            2. 1

                              Why do the packages do this, instead of the package manager?

                              1. 1

                                I’m confused by that question.

                                npm’s program has a post install hook that allows a package to run code. That code can do anything it wants in the context of the user’s access and authority. The reason for this hook existing is so the package can setup whatever it needs to be usable.

                                I think what you’re suggesting is that npm handle binary dependencies, which it could definitely do, but it there are a lot of diverse needs when it comes to just that use case that the feature would probably dwarf other things.

                                1. 1

                                  I’m not sure what’s confusing there.

                                  You mentioned downloading versions of packages generated for specific systems as something that packages handle themselves. It seems to me like figuring out what version of a package is needed and installing it is the job of the package manager.

                                  Ignoring sandboxing – it’s pointless, I’m going to run the code that gets installed anyways – having packages do it themselves seems like a lot of duplicated code and a lot of potential for bugs, MITM attacks, injections, etc. I doubt anyone is auditing them for certificate validation, SSL use, and other basics.

                                  1. 1

                                    You mentioned downloading versions of packages generated for specific systems as something that packages handle themselves. It seems to me like figuring out what version of a package is needed and installing it is the job of the package manager.

                                    Here’s an example of what a package might do with a postinstall process: https://github.com/sass/node-sass/blob/master/scripts/build.js

                                    There is no realistic way for npm (or rubygems or pip or…) to both be simple and also handle all usecases for a postinstall process.

                                    It’s all or nothing, IMO.

                    2. 5

                      Many developers, past me included, forget that some basic vetting is required before pulling open-source code into your apps. If it is something large and well supported like various Node or Ruby libraries then you can be pretty confident, but pulling in something small, in size or in usage, should be done carefully. Doing something simple like checking install scripts, availability of documentation or reputability of the developer(s) should be enough to give you some sense of trust.

                      I wonder how difficult it would be to implement some kind of checks during the install process to make sure the library isn’t making network connections or writing files outside of the install path.

                      1. 3

                        Some repos have introduced (or plan to introduce) quality metrics of various sorts. Integrating these into the CLI clients might be a good start. For example, in my .npmrc (or whatever, I don’t use Node) I would specify that I want a warning if dependency resolution on any project ever results in pulling down a package with a score below X and a full-on failure if the score is below Y.

                        Of course this assumes that the scores are sufficiently difficult to game and that there is enough variance in scores that people can draw meaningful lines in the sand for their projects.

                      2. 5

                        The fact that things like this can happen has long been acknowledged by npm, but not much has happened. See this post from March 2016: http://blog.npmjs.org/post/141702881055/package-install-scripts-vulnerability

                        Did a RFC for Yarn myself a week ago to try address these very concerns by allowing one to opt-in just the modules one actually needs to run scripts and have the scripts of the rest be ignored: https://github.com/yarnpkg/rfcs/pull/76

                        1. 9

                          Startup idea: a walled garden of node modules. Throw your money at me.

                          1. 1

                            I hope that’s a joke. The answer to this is isolation on the developer, language, and user side, not turning open source into a closed walled garden.

                            1. 2

                              You can always “sideload” anything you want, but there’s no reason why any random bozo should be able to upload packages to a trusted repository. Can I upload a malicious “pyhton” package to Debian? Is Debian not open source?

                              1. 2

                                Can I upload a malicious “pyhton” package to Debian? Is Debian not open source?

                                Debian is far from ideal, and vulnerable code containing exploits is uploaded to their repos constantly. The NPM repo is also quality-controlled by NPM Inc. (They removed the offending packages shortly after this tweet was posted.)

                                The answer is to fix the root of the problem, not the symptoms.

                                The root of the problem is that you cannot know whether code is malicious or harmful, even when you have, as Debian and NPM do, a controlled and vetted repository.

                                We need people to focus on fixing that, not wasting time on fake solutions that do nothing to address the actual problem.

                                People like Joanna Rutkowska are pioneers in this regard, for they are creating systems that can remain secure even when exploited. Others, like the Rustlang and RedoxOS devs, are also pioneers in this regard, for they are creating and using languages that simply eliminate entire classes of exploits.

                                1. 5

                                  I didn’t say Debian guaranteed original packages are bug free. But they have so far done a better job than npm keeping random bozos from uploading typo squatting imposter packages into their repo.

                                  I have no idea how rust is relevant here. Malicious rust code is still malicious.

                                  1. 1

                                    I have no idea how rust is relevant here. Malicious rust code is still malicious.

                                    I only brought it up as an example of a real solution to the problem of systemic software insecurity. Non-malicious-but-vulnerable code is also a problem that must be dealt with, and an example of something attempts at curation cannot fix.

                                  2. 1

                                    I actually doubt that there is any issue here. Registries are here to provide storage and an interface to fetch packages, they’re not here - and shouldn’t be - to audit the code, check squatting, and other stuff.

                                    When you use a package from the registry, it’s YOUR duty to check whether it’s safe or not, some people/company would accept some risks, some wouldn’t even consider them.

                                    1. 1

                                      I don’t think we’re in any disagreement.

                              2. 1

                                I’ve been trying to think of a way to get people to actually pay for this for years now :-/

                                1. 1

                                  So, anaconda for Node?