1. 16
  1.  

  2. 11

    Second, on November 2 we received a report to our security bug bounty program of a vulnerability that would allow an attacker to publish new versions of any npm package using an account without proper authorization. (snip) This vulnerability existed in the npm registry beyond the timeframe for which we have telemetry to determine whether it has ever been exploited maliciously.

    This is a scary bug.

    1. 10

      I think the two biggest stories here are:

      1. NPM had a bug where anyone could publish a new version of any package. The vulnerability has existed forever, and they have no way of knowing whether it has been exploited.
      2. GitHub tried to bury the announcement of that vulnerability by putting it in the last third of a long article full of mostly boring corporate speak when it really, really ought to have been its own security advisory.
    2. 2

      This is exactly why I refuse to use npm, pip, etc. I only use the OS’s package manager, which uses a cryptographically signed package repo. I absolutely hate these hacks of workarounds.

      1. 1

        And you are sure that zero packagers use NPM or pip as a source for the OS packages and not the source repo? (Am I being paranoid now?)

        1. 1

          I’m sure there are. And I hate that. But at least it’s going through my OS’s package manager, making it easy to use a single interface for auditing potential security issues.

        2. 1

          The issue is that sometimes you’re much much behind. For example python-cryptography is still stuck at 3.2.1 on RHEL8… So either you use pip… or a very old version…

          1. 1

            Fortunately, that’s not an issue I have being a BSD user using the nearly-always-up-to-date ports tree. I enjoy up-to-date software on a regular basis. Minimal lag between when a project’s release is published and when the ports tree gets updated to the new version.

            1. 2

              How is this different than using pip? You manually download the file?!

              1. 3

                The problem with per-language package repos like npm is that anyone and everyone has access to upload their project. That inherently means users must trust the most malicious of developers who upload malware to the repo.

                In the case of FreeBSD ports, the ports tree is gated by FreeBSD developers who have the opportunity to audit every single part of creating new ports or updating existing ports. It’s much easier to place trust in a (relatively) small set of developers who ensure sanity before committal.

                The package manager I use for my system (FreeBSD’s pkg) makes it incredibly easy to audit packages, even checking something called VuXML to check if any of your installed packages have known vulnerabilities. I can see which files (config, lib, application, etc.) have changed from their default since pkg tracks hashes for each file it installs. Additionally, the package repo itself is cryptographically signed so that it’s not possible to inject malicious code in transit. If the server hosting the package repo is compromised, there’s no problem since the private crypto key material is stored elsewhere. And this bit of crypto is protected by the OS itself.

                1. 1

                  That’s fine in theory, but when someone packages a program for FreeBSD that uses a language-specific package manager, they use the built-in infrastructure in the ports tree that downloads the dependencies, then packages them in distfiles and records their hash. This is no more secure than pulling from upstream directly. The folks that package things for FreeBSD aren’t auditing the upstream any more than npm / pip / gem / whatever does.

                  The only thing that the signature gives you is an attestation that the package was built on a FreeBSD build machine and has not been tampered with between there and you by anyone who did not have access to the signing key. It does not give you any assurance that the build machine wasn’t compromised or that there weren’t supply-chain vulnerabilities upstream from the builders.

                  Most FreeBSD packages don’t use reproduceable builds, so you don’t have any assurance that your packages contain the code that they claimed they did: if you try to rebuild locally from the same port, you may or may not get the same binary. Is the one you got trojaned? Who knows.

                  pkg audit is great, but npm and friends have similar things that tell you if there are published vulnerabilities in their libraries. They have two problems:

                  • They tell you only about published vulnerabilities. Good projects will go through the process of getting a CVE assigned and doing coordinated disclosure. Others just push out a new version. The auditing tools tell you only about the former.
                  • They are very coarse-grained. They don’t let you know if the vulnerability in a library is on a code path used by anything you have installed and they don’t let you know if that codepath (if it is reachable) is using any data that can be influenced by an attacker. So pkg audit shows a vulnerability in curl’s URL parsing. Does it matter? Is curl used only with trusted URLs? Maybe it’s fine, but can a server-side redirect trigger it?
              2. 1

                How minimal?

                1. 2

                  Sometimes minutes. Sometimes hours. Sometimes days. It depends on the time and resources of a volunteer-run project. For example, I’ve seen FreeBSD update the Tor port just minutes after a new release. FreeBSD generally updates Firefox to RC releases so that we can test what will be the next version before it comes out (which means we have a negative time window in this particular case.)

                  1. 1

                    Sometimes minutes. Sometimes hours. Sometimes days.

                    So basically the same boat as rhel then