14 ms·

> However, the service that performs underlying updates to the registry data determined which package to publish based on the contents of the uploaded package f

by jschrf 5y ago

> However, the service that performs underlying updates to the registry data determined which package to publish based on the contents of the uploaded package file Yeah, this is what's going to keep me up tonight. Yikes. I can't help but wonder if the root cause was HTTP request smuggling, or if changing package.json was enough. How do we even mitigate against these types of supply-chain attacks, aside from disabling run-scripts, using lockfiles and carefully auditing the entire dependency tree on every module update? I'm seriously considering moving to a workflow of installing dependencies in containers or VMs, auditing them there, and then perhaps commiting known safe snapshots of node_modules into my repos (YUCK). Horrible developer experience, but at least it'll help me sleep at night.

grey-area 5y ago
How do we even mitigate against these types of supply-chain attacks Don’t import thousands of modules from third parties just to write a simple web app. If you have 10 stable dependencies it’s no problem to vendor them and vet changes. If you have 10k you’ve entirely given up on any pretence of security.
- vosper 5y ago
  People don't directly import thousands of modules. It's actually a lot closer to your "10 stable dependencies". But those dependencies have dependencies that have dependencies. It's a little hard to point the finger at application developers here, IMO.
  - pdonis 5y ago
    > It's a little hard to point the finger at application developers here, IMO. I disagree. Any application developer who seriously thinks that they only have 10 dependencies if they're only importing directly 10 dependencies should not be an application developer in the first place.
    - IggleSniggle 5y ago
      You sure about that? Even if you’re writing just for a vetted distribution of an OS, and you write code with zero explicit dependencies, you still have much more than zero dependencies. It’s turtles all the way down. The key is to have an entire ecosystem that you can, to some degree more or less, trust.
      - marcus_holmes 5y ago
        No. we've been shouting warnings for years. There have been dozens, if not hundreds of threads on HN alone warning of supply-chain security threats. At this point if you're not actively auditing your dependencies, and reducing all of them where you can, then you're on the wrong side of history and going down with the Titanic. The frank truth is that including a dependency is, and always has been, giving a random person from the internet commit privileges to prod. The fact that "everyone else did it" doesn't make it less stupid.
        erulabs 5y ago
        > The frank truth is that including a dependency is, and always has been, giving a random person from the internet commit privileges to prod I mean, no. This is hyperbole at best and just wrong at median. A system of relative trust has worked very well for a very long time - Linus doesn’t have root access to all our systems, even if we don’t have to read every line of code.
        chha 5y ago
        Linus doesn't have root access to our systems for several reasons. One of them is the fact that we get the actual source code, and not just a compiled blob doing "something". Another is the fact that they have at least some level of reviews wrt who can commit code, although this isn't perfect as the case with the University of Minnesota proved. Npm on the other hand is much, much worse. Anyone can publish anything they want, and they can point to any random source code repository claiming that this is the source. If we look at how often vulnerable packages are discovered in eg. npm, I'd argue that the current level of trust and quality aren't sustainable, partly due to the potentially huge number of direct and transitive dependencies a project may have. Unless you start to review the actual component you have no way to verify this, and unlike the Linux kernel there is no promise that anyone has ever reviewed the package you download. You can of course add free tools such as the OWASP Dependency Check, but these will typically lag a bit behind as they rely on published vulnerabilities. Other tools such as the Sonatype Nexus platform is more proactive, but can be expensive.
  - nitwit005 5y ago
    I mean, you say that, but the practice of pulling in so many dependencies is fairly recent. It wasn't even possible for most projects before everyone had fast internet.
  - dpweb 5y ago
    Some of the comments in this thread are wild. Huge dependency trees are bad pattern, plain and simple. The problem isn’t only ridiculous amounts of untrusted code, but thousands of new developers of the last 10 years who think this is the way to write reliable code. Never acknowledged the risks of having everyone write your code for you, and overestimate how unique and interesting their apps are. If you must participate in this madness, static analysis tools exist to scan your 10000 dependencies, taking security seriously is the issue.
    - deleted 5y ago
      [deleted]
    - noway421 5y ago
      Most of those dependencies have well defined, stable api. They use or at least try to follow semver. And you're probably only hitting about 10% of your dependencies on the critical path you're using, meaning that a lot of potentially vulnerable code is never executed. I get the supply chain attacks. I get that you have a tree of untrusted javascript code that you're executing in your app, on install, on build and in runtime. But there's also Snyk and Dependabot which issue you alerts when your dependency tree has published CVEs. We can talk about alert fatigue, but to be honest, I feel more secure with my node_modules folder than I do with my operating system and plethora of DLLs it loads. I don't wanna turn this into a whataboutism argument, but at some point you gotta get to work, write some code and depend on some libraries other people have written.
      - laurent92 5y ago
        > Snyk and Dependabot Wait, I’m not safe using “npm audit”?
      - grey-area 5y ago
        Semver will not save you.
      - ptx 5y ago
        > And you're probably only hitting about 10% of your dependencies on the critical path you're using, meaning that a lot of potentially vulnerable code is never executed. If a dependency has been compromised it doesn't matter if its code is actually used, since it can include a lifecycle script that's executed at install-time, which was apparently the mechanism for the recent ua-parser-js exploit.
  - grey-area 5y ago
    This is the direct result of the culture of tiny dependencies in JS and some other languages, but not all ecosystems are like this. If you choose to use node, this is where you end up, but it was a choice. Many languages have a decent standard library which covers most of the bases, so it’s possible to have a very restricted set of dependencies.
    - jschrf 5y ago
      Unfortunately for frontend and the Node ecosystem, it's too late to try and put the toothpaste back in the tube. Hopefully Deno helps with this pain point.
- shadowgovt 5y ago
  That's going to be incompatible with writing interesting software on the web, unless we want to just hand the problem over to a handful of big players who can afford to hand-vet 10,000 dependencies. The reason packages are so big is the complexity for an interesting app is irreducible. People don't import thousands of modules for fun; they do it because simple software tends towards requiring complex underpinning. Consider the amount of operating system that underlies a simple "Hello, world!" GUI app. And since the browser-provided abstractions are trash for writing a web app, people swap them out with frameworks. I'm working on a React app right now where I've imported about a dozen dependencies explicitly (half of which are TypeScript @type files, so closer to a half-dozen). The total size of my `node_modules` directory is closer to a couple hundred packages. It's 35MB of files. And no, I couldn't really leave any of them out to do the thing I want to do, unfortunately.
  - rhizome 5y ago
    I have to think there's a lot of YAGNI going on, dependencies that are included to be a better version of native functionality. A faster JSON parser, say, with I dunno, 20 dependencies (a count which may further extend within those deps) for something where slow JSON parsing has not yet become an issue. I think there's a lot of "academic" inclusions out there like this.
    - endless1234 5y ago
      My experience working on tens of front end projects is the complete opposite. Nobody is adding dependencies just for the fun of it, or because you might need it in a year. You add a dependency because you need some functionality and there is no time/budget to re-do it in house - not to mention that if it's a well-supported library with, for example, hundreds of thousands of users, it's unlikely you could even make it better.
      - cxr 5y ago
        > there is no time/budget to re-do it in house What are the actual time cost savings when you take the total costs into consideration?[1][2] What would it look like if you didn't implement an app by stringing together dozens/hundreds/thousands of third-party modules implemented bottom-up, but instead took control of the whole thing top-down?[3] 1. https://jvns.ca/blog/2021/11/15/esbuild-vue/ https://jvns.ca/blog/2021/11/15/esbuild-vue/ 2. https://news.ycombinator.com/item?id=24495646 https://news.ycombinator.com/item?id=24495646 3. https://www.teamten.com/lawrence/programming/write-code-top-down.html https://www.teamten.com/lawrence/programming/write-code-top-...
- ncc-erik 5y ago
  I only imported 10 dependencies, but those 10 dependencies each had 10 dependencies which each had 10 dependencies which each had 10 dependencies and all of the sudden I'm at 10k dependencies again...
  - nirvdrum 5y ago
    The transitive dependency chain should be part of your evaluation of a library. Frameworks are special cases, for sure. But if you’re adding a dependency and it adds 10,000 new entries to your lock file, that should be taken into consideration during your library selection process. Likewise, when upgrading dependencies, you should watch how much of the world gets pulled in. That said, I don’t know what the answer is for JS. There are too many dependency cycles that make auditing upgrades intractable. If you’re not constantly upgrading libraries, you’ll be unable to add a new one because it probably relies on a newer version of something you already had. In most other ecosystems, upgrading can be a more deliberate activity. I tried to audit NPM module upgrades and it’s next to impossible if using something like Create React App. The last time I tried Create React App, yarn-audit reported ~5,000 security issues on a freshly created app. Many were duplicates due with the same module being depended on multiple times, but it’s still problematic.
- edgyquant 5y ago
  What’s the alternative? Writing everything in house? I think a better solution would be a better dependency installer/resolver that is as secure as possible.
  - evilduck 5y ago
    Frameworks and library authors could stand to do more in-house. It's also on devs to vet a library for maintenance concerns like sprawling dependencies.
  - lawl 5y ago
    > What’s the alternative? Don't use the popular hype garbage. Yes, I realize that may not be an option for a lot of people professionally. But I believe if you actually spend some time on due diligence for any dependency you consider adding, you can significantly reduce the number of untrusted deps you pull in. One of the problems of course is that javascript exacerbates this problem somewhat by not having a comprehensive standard library. But whenever I look for go libraries, go.sum is usually one of the first files I click to check how much garbage it pulls in.
    - noway421 5y ago
      Standard library is a dependency too and can have bugs in it. What's better - having stdlib tied to the runtime release schedule or having a lot of micro libraries on their own rolling release schedule which can quickly release security patches? I agree, having those dependencies authored by Node.js Foundation itself will yield higher level of trust. But we're all human, and one can argue earnest open source developers have better aligned incentives than a randomly selected Node.js Foundation employee. I honestly am not sure I fully agree with what I've just written above either. But one thing I would want to pinpoint: those things are NOT black and white. The specific set of trade offs the Node.js ecosystem fallen into might look accidental and inadequate. But I think it's fairly reasonable.
      - grey-area 5y ago
        Yes using a standard library is better. It is more stable, trustworthy and maintained by a small group of people.
- krono 5y ago
  Recently Node 16 LTS cycle started. One month and a few days before the carry-over, a super controversial package titled `coredeps` [0] was officially declared a core module and has been bundled with all official distributions since. The NodeJS team refuses to discuss NPM because it's a separate 3rd party. And yet.... this NodeJS Core module comes pre-installed as a global NPM package. We're just getting started. This module installs or even reinstalls any supported package manager when you execute a script with a name that would match any that they'd recognise. Opt-in for only a short period, and intending to expand beyond package manager installations. Amidst all that's been going on, NPM (Nonstop Published Moments) is working on a feature that silently hijacks user commands and installs foreign software. The code found in those compromised packages operated in a similar manner and was labeled a critical severity vulnerability. The following might actually make you cry. Of these third party remote distributions it's downloading, the number of checksum, keys, or even build configurations that are being verified is 0. The game that Microsoft is playing with their recent acquisitions here is quite clear, but there's too much collateral damage. [0] https://github.com/nodejs/corepack#readme https://github.com/nodejs/corepack#readme
  - arcatek 5y ago
    To reiterate on what sibling comments said, I'm the one who spawned the discussion and implementation of Corepack, and npm remained largely out of it; the push mostly came from pnpm and Yarn. Additionally, unlike other approaches, Corepack ensures that package manager versions are pinned per project and you don't need to blindly install newest ones via `npm i -g npm` (which could potentially be hijacked via the type of vulnerability discussed here). It intends to make your projects more secure, not less.
    - krono 5y ago
      If anything this makes it worse. - No security checks are present in the package manager download and installation process so there are still no guarantees. - Existing installations of package managers are automatically overwritten when the user calls their binary. What if this was a custom compilation or other customisations were made? - This solution does a lot more behind the scenes than just run that yarn command that the user asked for but hand't installed. - Why not simply notify the user when their package manager isn't installed or only allow it with a forced flag? (As has been suggested uncountable times by numerous people anywhere this topic came up over the years.) Disrespecting user autonomy, capacity to self-regulate, and ownership over their machine and code is not the way. Edit: Formatting
- HWR_14 5y ago
  How do you police what your imports import? Serious question. Let's say I'm building a Discord app (as I want to do.) Well, either NPM or Python PIP to get one module - the discord module. But who knows how safe what it imports is. That's the point. Are there stable dependencies from reputable companies that do the things I want without me vetting 10k submodule imports?
  - skinkestek 5y ago
    I somewhat naively assume that at least if I use plain React or Angular then - someone at Facebook or Google has vetted the dependcy graph for those - I also assume they have internal Snyk-like tools - I also assume other users have similar tools so someone should catch it. When it comes to anything else I often look into what it pulls in. Also I keep an eye on the yarn.lock-file in pull requests.
    - ptx 5y ago
      This requires that you're pulling in only exactly the same versions of those dependencies as those that Facebook and Google have vetted. Is there a way to do that?
    - filoeleven 5y ago
      > so someone should catch it. Just a week or two ago, a malicious NPM package was published which, for the hour or so that it was up, would be pulled in by any installation of create-react-app, since somewhere in the dependency tree it was specified with “^” to allow for minor updates. Any machine that ran “npm -i” with CRA or who knows how many other projects during that hour may have compromised credentials. 1 hour to find and unpublish the malicious package is a fast turnaround time, so someone was watching and that’s great. But any NPM tree that includes anything other than fully-specified and locked versions all the way down the tree is just waiting for the next shoe to drop.
    - HWR_14 5y ago
      So my specific usecase (write a Discord bot) has the solution of "write everything from scratch" or "don't use JS"? That's kinda what I assumed, but "only run code that have been signed off on by a major company" is kinda a shitty solution.
- adolph 5y ago
  Maybe 10 stable dependencies without dependencies? Otherwise it's dependencies all the way down. Is vendoring in a dependency just slowing things down? Slows down development and bakes existing attacks in longer.
- veeti 5y ago
  Unfortunately most modern JavaScript tooling has made this very difficult. Before you even have a "hello world" app running create-react-app et al. will install literally a thousand random packages. It's already over.
- deleted 5y ago
  [deleted]
secondaryacct 5y ago
It s very easy: add a dev signature in the repo that cannot be changed ever, and force the devs to sign their stuff before allowing a change of binary or a download. Like that you can have anything trying to upload but fail the signature check.
- nathanaldensr 5y ago
  This assumes that the developers themselves are not malicious (see: left-pad) and that their signing keys can't be stolen.
staticassertion 5y ago
A combination of things, I think. 1. Running those builds in VMs is a good idea. 2. Monitoring for weird behavior. 3. Restricting build scripts from touching anything outside of the build directory. 4. Pressuring organizations like npm to step up their security game. It would be really nice if package repositories: 1. Produced a signed audit log 2. Supported signing keys for said audit log 3. Supported strong 2FA methods 4. Created tooling that didn't run build scripts with full system access etc etc etc I started working on a crates.io mirror and a `cargo sandbox [build|check|etc]` command that would allow crates to specify a permissions manifest for their build scripts, store the policy in a lockfile, and then warn you if a locked policy increased in scope. I'm too busy to finish it but it isn't very hard to do.
- jschrf 5y ago
  Thanks. I was thinking of a CI step that checked the SHA-256 of yarn.lock against a "last known good" value committed by an authorized committer and enforced by a branch policy. Signed audit logs seem like a good idea. Now...how to get developers to avoid using NPM and Yarn altogether on sensitive projects...
deleted 5y ago
[deleted]
1propionyl 5y ago
> I can't help but wonder if the root cause was HTTP request smuggling, or if changing package.json was enough. Maybe I'm just incredibly cynical from my experiences with the intersection of the JS ecosystem and security, but... ...I'd bet dimes to dollars it's the latter (just changing the package.json). My guess is they authenticate but don't actually scope the authentication properly, and no one noticed because no one thought to look. Of course, as we've seen in the past decade, there's so much inertia behind the JavaScript ecosystem that none of this is going to fundamentally change. It'll just take another decade or so for the ecosystem to reinvent all of the wheels and catch up to the rest of the space. And at that point it will probably be considered stuffy and "enterprise" and the new hotness unburdened from such concerns will repeat the cycle again.
- mhio 5y ago
  > to reinvent all of the wheels and catch up to the rest of the space. Which of the public package systems are the state of the art that should be replicated?
  - thrashh 5y ago
    Java’s works really well. I think it makes other package managers look like a toy.
    - mhio 5y ago
      I assume you are referring to Apache Maven tooling (and compatible) and the pom repos, like Sonatype's Central Repo. PGP package signing is a huge plus. Is that a requirement for publishing? How many different repo's do you typically have to deal with in the average project? Would Sonatype react quickly to malware issue's like this in the repository? Have there been examples of similar package hijacking?
      - thrashh 5y ago
        It’s a requirement for the central repo if I recall. And the best past is the signature handling is a part of Java, not the package manager, so nothing needs to be re-invented. The default class loader checks the signatures at runtime as well. Typically you need 1-2 repositories, but often just 1. But if you’re an organization, you can set up your own repository very easily and use it to store private deps and to cache deps (which also allows you to lock binaries and work offline). Repo mirroring is super easy to set up. If you have an internal repo, you can just have your internal project use your own repo and your computer never has to directly reach outside the Internet for a package. Unlike other languages, the “central repo” and the package manager tooling are independent and package resolution is distributed. When you start a project, you choose your repos. I don’t know how quickly Sonatype would react personally but they are only default by de facto. Many packages are published on several repos and mirroring is a default feature of a lot of repo software. If Sonatype started screwing up, everyone could abandon them instantly, which forces them to be better.
snthd 5y ago
>How do we even mitigate against these types of supply-chain attacks, aside from disabling run-scripts, using lockfiles and carefully auditing the entire dependency tree on every module update? Don't trust the package distribution system - use public key crypto.
- hn_throwaway_99 5y ago
  Public key crypto doesn't help much if your private keys get stolen, which was essentially what happened with some of the recent hacked packages and which is why they're now starting to enforce 2FA.
  - woodruffw 5y ago
    The longer term solution to this is public key signatures with an ephemeral key, rooted to some trusted identity source (e.g., a GitHub account with strong 2FA). There’s lots of work on that front coming out of the Open Source Security Foundation.
  - onefuncman 5y ago
    are you really using private keys without a passphrase in 2021?
0xDEAFBEAD 5y ago
>How do we even mitigate against these types of supply-chain attacks I know HN is usually skeptical of anything cryptocurrency/blockchain related, and I am too. But as weird as it sounds, I think blockchain might actually be the solution here. The problem with dependency auditing is it's a lot of work. And it's also duplicate work. What you'd really like to know is whether the dependency you're considering has already been audited by someone you can trust. Ideally someone with skin in the game. Someone who stands to lose something if their audit is incorrect. Imagine a DeFi app that lets people buy and sell insurance for any commit hash of any open source library. The insurance pays out if a vulnerability in that commit hash is found. * As a library user, you want to buy insurance for every library you use. If you experience a security breach, the money you get from the insurance will help you deal with the aftermath. * As an independent hacker, you can make passive income by auditing libraries and selling insurance for the ones that seem solid. If you identify a security flaw, buy up insurance for that library, then publicize the flaw for a big payday. * A distributed, anonymous marketplace is actually valuable here, because it encourages "insider trading" on the part of people who work for offensive cybersecurity orgs. Suppose Jane Hacker is working with a criminal org that's successfully penetrated a particular library. Suppose Jane wants to leave her life of crime behind. All she has to do is buy up insurance for the library that was penetrated and then anonymously disclose the vulnerability. * Even if you never trade on the insurance marketplace yourself, you can get a general idea of how risky a library is by checking how much its insurance costs. (Insurance might be subject to price manipulation by offensive cybersecurity orgs, but independent hackers would be incentivized to identify and correct such price manipulation.) The fact that there is actual value here should give the creator a huge advantage over other "Web 3.0" crypto junk.
- jschrf 5y ago
  This is a pretty clever application of DeFi, thanks. DeSec? Can't help but wonder if there still would be incentive for lone wolves to slip backdoors and vulnerabilities into libraries though[0]. [0]: https://portswigger.net/daily-swig/smuggling-hidden-backdoors-into-javascript-with-homoglyphs-and-invisible-unicode-characters https://portswigger.net/daily-swig/smuggling-hidden-backdoor...
Silhouette 5y ago
I'm seriously considering moving to a workflow of installing dependencies in containers or VMs, auditing them there, and then perhaps commiting known safe snapshots of node_modules into my repos (YUCK). Horrible developer experience, but at least it'll help me sleep at night. I have had people tell me in discussions online, also entirely seriously, that running a package manager to install a dependency while developing is inherently dangerous and anyone who does it outside of a disposable sandboxed VM deserves everything they get. If the packages are inexplicably allowed to do arbitrary things with privileged access to the local system without warning at installation time then clearly the first part is correct, but victim-blaming hardly seems like a useful reaction to that danger.

by jschrf 5y ago

grey-area 5y ago

How do we even mitigate against these types of supply-chain attacks Don’t import thousands of modules from third parties just to write a simple web app. If you have 10 stable dependencies it’s no problem to vendor them and vet changes. If you have 10k you’ve entirely given up on any pretence of security.

vosper 5y ago
People don't directly import thousands of modules. It's actually a lot closer to your "10 stable dependencies". But those dependencies have dependencies that have dependencies. It's a little hard to point the finger at application developers here, IMO.
- pdonis 5y ago
  > It's a little hard to point the finger at application developers here, IMO. I disagree. Any application developer who seriously thinks that they only have 10 dependencies if they're only importing directly 10 dependencies should not be an application developer in the first place.
  - IggleSniggle 5y ago
    You sure about that? Even if you’re writing just for a vetted distribution of an OS, and you write code with zero explicit dependencies, you still have much more than zero dependencies. It’s turtles all the way down. The key is to have an entire ecosystem that you can, to some degree more or less, trust.
    - marcus_holmes 5y ago
      No. we've been shouting warnings for years. There have been dozens, if not hundreds of threads on HN alone warning of supply-chain security threats. At this point if you're not actively auditing your dependencies, and reducing all of them where you can, then you're on the wrong side of history and going down with the Titanic. The frank truth is that including a dependency is, and always has been, giving a random person from the internet commit privileges to prod. The fact that "everyone else did it" doesn't make it less stupid.
      - erulabs 5y ago
        > The frank truth is that including a dependency is, and always has been, giving a random person from the internet commit privileges to prod I mean, no. This is hyperbole at best and just wrong at median. A system of relative trust has worked very well for a very long time - Linus doesn’t have root access to all our systems, even if we don’t have to read every line of code.
        chha 5y ago
        Linus doesn't have root access to our systems for several reasons. One of them is the fact that we get the actual source code, and not just a compiled blob doing "something". Another is the fact that they have at least some level of reviews wrt who can commit code, although this isn't perfect as the case with the University of Minnesota proved. Npm on the other hand is much, much worse. Anyone can publish anything they want, and they can point to any random source code repository claiming that this is the source. If we look at how often vulnerable packages are discovered in eg. npm, I'd argue that the current level of trust and quality aren't sustainable, partly due to the potentially huge number of direct and transitive dependencies a project may have. Unless you start to review the actual component you have no way to verify this, and unlike the Linux kernel there is no promise that anyone has ever reviewed the package you download. You can of course add free tools such as the OWASP Dependency Check, but these will typically lag a bit behind as they rely on published vulnerabilities. Other tools such as the Sonatype Nexus platform is more proactive, but can be expensive.
- nitwit005 5y ago
  I mean, you say that, but the practice of pulling in so many dependencies is fairly recent. It wasn't even possible for most projects before everyone had fast internet.
- dpweb 5y ago
  Some of the comments in this thread are wild. Huge dependency trees are bad pattern, plain and simple. The problem isn’t only ridiculous amounts of untrusted code, but thousands of new developers of the last 10 years who think this is the way to write reliable code. Never acknowledged the risks of having everyone write your code for you, and overestimate how unique and interesting their apps are. If you must participate in this madness, static analysis tools exist to scan your 10000 dependencies, taking security seriously is the issue.
  - deleted 5y ago
    [deleted]
  - noway421 5y ago
    Most of those dependencies have well defined, stable api. They use or at least try to follow semver. And you're probably only hitting about 10% of your dependencies on the critical path you're using, meaning that a lot of potentially vulnerable code is never executed. I get the supply chain attacks. I get that you have a tree of untrusted javascript code that you're executing in your app, on install, on build and in runtime. But there's also Snyk and Dependabot which issue you alerts when your dependency tree has published CVEs. We can talk about alert fatigue, but to be honest, I feel more secure with my node_modules folder than I do with my operating system and plethora of DLLs it loads. I don't wanna turn this into a whataboutism argument, but at some point you gotta get to work, write some code and depend on some libraries other people have written.
    - laurent92 5y ago
      > Snyk and Dependabot Wait, I’m not safe using “npm audit”?
    - grey-area 5y ago
      Semver will not save you.
    - ptx 5y ago
      > And you're probably only hitting about 10% of your dependencies on the critical path you're using, meaning that a lot of potentially vulnerable code is never executed. If a dependency has been compromised it doesn't matter if its code is actually used, since it can include a lifecycle script that's executed at install-time, which was apparently the mechanism for the recent ua-parser-js exploit.
- grey-area 5y ago
  This is the direct result of the culture of tiny dependencies in JS and some other languages, but not all ecosystems are like this. If you choose to use node, this is where you end up, but it was a choice. Many languages have a decent standard library which covers most of the bases, so it’s possible to have a very restricted set of dependencies.
  - jschrf 5y ago
    Unfortunately for frontend and the Node ecosystem, it's too late to try and put the toothpaste back in the tube. Hopefully Deno helps with this pain point.
shadowgovt 5y ago
That's going to be incompatible with writing interesting software on the web, unless we want to just hand the problem over to a handful of big players who can afford to hand-vet 10,000 dependencies. The reason packages are so big is the complexity for an interesting app is irreducible. People don't import thousands of modules for fun; they do it because simple software tends towards requiring complex underpinning. Consider the amount of operating system that underlies a simple "Hello, world!" GUI app. And since the browser-provided abstractions are trash for writing a web app, people swap them out with frameworks. I'm working on a React app right now where I've imported about a dozen dependencies explicitly (half of which are TypeScript @type files, so closer to a half-dozen). The total size of my `node_modules` directory is closer to a couple hundred packages. It's 35MB of files. And no, I couldn't really leave any of them out to do the thing I want to do, unfortunately.
- rhizome 5y ago
  I have to think there's a lot of YAGNI going on, dependencies that are included to be a better version of native functionality. A faster JSON parser, say, with I dunno, 20 dependencies (a count which may further extend within those deps) for something where slow JSON parsing has not yet become an issue. I think there's a lot of "academic" inclusions out there like this.
  - endless1234 5y ago
    My experience working on tens of front end projects is the complete opposite. Nobody is adding dependencies just for the fun of it, or because you might need it in a year. You add a dependency because you need some functionality and there is no time/budget to re-do it in house - not to mention that if it's a well-supported library with, for example, hundreds of thousands of users, it's unlikely you could even make it better.
    - cxr 5y ago
      > there is no time/budget to re-do it in house What are the actual time cost savings when you take the total costs into consideration?[1][2] What would it look like if you didn't implement an app by stringing together dozens/hundreds/thousands of third-party modules implemented bottom-up, but instead took control of the whole thing top-down?[3] 1. https://jvns.ca/blog/2021/11/15/esbuild-vue/ https://jvns.ca/blog/2021/11/15/esbuild-vue/ 2. https://news.ycombinator.com/item?id=24495646 https://news.ycombinator.com/item?id=24495646 3. https://www.teamten.com/lawrence/programming/write-code-top-down.html https://www.teamten.com/lawrence/programming/write-code-top-...
ncc-erik 5y ago
I only imported 10 dependencies, but those 10 dependencies each had 10 dependencies which each had 10 dependencies which each had 10 dependencies and all of the sudden I'm at 10k dependencies again...
- nirvdrum 5y ago
  The transitive dependency chain should be part of your evaluation of a library. Frameworks are special cases, for sure. But if you’re adding a dependency and it adds 10,000 new entries to your lock file, that should be taken into consideration during your library selection process. Likewise, when upgrading dependencies, you should watch how much of the world gets pulled in. That said, I don’t know what the answer is for JS. There are too many dependency cycles that make auditing upgrades intractable. If you’re not constantly upgrading libraries, you’ll be unable to add a new one because it probably relies on a newer version of something you already had. In most other ecosystems, upgrading can be a more deliberate activity. I tried to audit NPM module upgrades and it’s next to impossible if using something like Create React App. The last time I tried Create React App, yarn-audit reported ~5,000 security issues on a freshly created app. Many were duplicates due with the same module being depended on multiple times, but it’s still problematic.
edgyquant 5y ago
What’s the alternative? Writing everything in house? I think a better solution would be a better dependency installer/resolver that is as secure as possible.
- evilduck 5y ago
  Frameworks and library authors could stand to do more in-house. It's also on devs to vet a library for maintenance concerns like sprawling dependencies.
- lawl 5y ago
  > What’s the alternative? Don't use the popular hype garbage. Yes, I realize that may not be an option for a lot of people professionally. But I believe if you actually spend some time on due diligence for any dependency you consider adding, you can significantly reduce the number of untrusted deps you pull in. One of the problems of course is that javascript exacerbates this problem somewhat by not having a comprehensive standard library. But whenever I look for go libraries, go.sum is usually one of the first files I click to check how much garbage it pulls in.
  - noway421 5y ago
    Standard library is a dependency too and can have bugs in it. What's better - having stdlib tied to the runtime release schedule or having a lot of micro libraries on their own rolling release schedule which can quickly release security patches? I agree, having those dependencies authored by Node.js Foundation itself will yield higher level of trust. But we're all human, and one can argue earnest open source developers have better aligned incentives than a randomly selected Node.js Foundation employee. I honestly am not sure I fully agree with what I've just written above either. But one thing I would want to pinpoint: those things are NOT black and white. The specific set of trade offs the Node.js ecosystem fallen into might look accidental and inadequate. But I think it's fairly reasonable.
    - grey-area 5y ago
      Yes using a standard library is better. It is more stable, trustworthy and maintained by a small group of people.
krono 5y ago
Recently Node 16 LTS cycle started. One month and a few days before the carry-over, a super controversial package titled `coredeps` [0] was officially declared a core module and has been bundled with all official distributions since. The NodeJS team refuses to discuss NPM because it's a separate 3rd party. And yet.... this NodeJS Core module comes pre-installed as a global NPM package. We're just getting started. This module installs or even reinstalls any supported package manager when you execute a script with a name that would match any that they'd recognise. Opt-in for only a short period, and intending to expand beyond package manager installations. Amidst all that's been going on, NPM (Nonstop Published Moments) is working on a feature that silently hijacks user commands and installs foreign software. The code found in those compromised packages operated in a similar manner and was labeled a critical severity vulnerability. The following might actually make you cry. Of these third party remote distributions it's downloading, the number of checksum, keys, or even build configurations that are being verified is 0. The game that Microsoft is playing with their recent acquisitions here is quite clear, but there's too much collateral damage. [0] https://github.com/nodejs/corepack#readme https://github.com/nodejs/corepack#readme
- arcatek 5y ago
  To reiterate on what sibling comments said, I'm the one who spawned the discussion and implementation of Corepack, and npm remained largely out of it; the push mostly came from pnpm and Yarn. Additionally, unlike other approaches, Corepack ensures that package manager versions are pinned per project and you don't need to blindly install newest ones via `npm i -g npm` (which could potentially be hijacked via the type of vulnerability discussed here). It intends to make your projects more secure, not less.
  - krono 5y ago
    If anything this makes it worse. - No security checks are present in the package manager download and installation process so there are still no guarantees. - Existing installations of package managers are automatically overwritten when the user calls their binary. What if this was a custom compilation or other customisations were made? - This solution does a lot more behind the scenes than just run that yarn command that the user asked for but hand't installed. - Why not simply notify the user when their package manager isn't installed or only allow it with a forced flag? (As has been suggested uncountable times by numerous people anywhere this topic came up over the years.) Disrespecting user autonomy, capacity to self-regulate, and ownership over their machine and code is not the way. Edit: Formatting
HWR_14 5y ago
How do you police what your imports import? Serious question. Let's say I'm building a Discord app (as I want to do.) Well, either NPM or Python PIP to get one module - the discord module. But who knows how safe what it imports is. That's the point. Are there stable dependencies from reputable companies that do the things I want without me vetting 10k submodule imports?
- skinkestek 5y ago
  I somewhat naively assume that at least if I use plain React or Angular then - someone at Facebook or Google has vetted the dependcy graph for those - I also assume they have internal Snyk-like tools - I also assume other users have similar tools so someone should catch it. When it comes to anything else I often look into what it pulls in. Also I keep an eye on the yarn.lock-file in pull requests.
  - ptx 5y ago
    This requires that you're pulling in only exactly the same versions of those dependencies as those that Facebook and Google have vetted. Is there a way to do that?
  - filoeleven 5y ago
    > so someone should catch it. Just a week or two ago, a malicious NPM package was published which, for the hour or so that it was up, would be pulled in by any installation of create-react-app, since somewhere in the dependency tree it was specified with “^” to allow for minor updates. Any machine that ran “npm -i” with CRA or who knows how many other projects during that hour may have compromised credentials. 1 hour to find and unpublish the malicious package is a fast turnaround time, so someone was watching and that’s great. But any NPM tree that includes anything other than fully-specified and locked versions all the way down the tree is just waiting for the next shoe to drop.
  - HWR_14 5y ago
    So my specific usecase (write a Discord bot) has the solution of "write everything from scratch" or "don't use JS"? That's kinda what I assumed, but "only run code that have been signed off on by a major company" is kinda a shitty solution.
adolph 5y ago
Maybe 10 stable dependencies without dependencies? Otherwise it's dependencies all the way down. Is vendoring in a dependency just slowing things down? Slows down development and bakes existing attacks in longer.
veeti 5y ago
Unfortunately most modern JavaScript tooling has made this very difficult. Before you even have a "hello world" app running create-react-app et al. will install literally a thousand random packages. It's already over.
deleted 5y ago
[deleted]

secondaryacct 5y ago

It s very easy: add a dev signature in the repo that cannot be changed ever, and force the devs to sign their stuff before allowing a change of binary or a download. Like that you can have anything trying to upload but fail the signature check.

nathanaldensr 5y ago
This assumes that the developers themselves are not malicious (see: left-pad) and that their signing keys can't be stolen.

staticassertion 5y ago

A combination of things, I think. 1. Running those builds in VMs is a good idea. 2. Monitoring for weird behavior. 3. Restricting build scripts from touching anything outside of the build directory. 4. Pressuring organizations like npm to step up their security game. It would be really nice if package repositories: 1. Produced a signed audit log 2. Supported signing keys for said audit log 3. Supported strong 2FA methods 4. Created tooling that didn't run build scripts with full system access etc etc etc I started working on a crates.io mirror and a `cargo sandbox [build|check|etc]` command that would allow crates to specify a permissions manifest for their build scripts, store the policy in a lockfile, and then warn you if a locked policy increased in scope. I'm too busy to finish it but it isn't very hard to do.

jschrf 5y ago
Thanks. I was thinking of a CI step that checked the SHA-256 of yarn.lock against a "last known good" value committed by an authorized committer and enforced by a branch policy. Signed audit logs seem like a good idea. Now...how to get developers to avoid using NPM and Yarn altogether on sensitive projects...

deleted 5y ago

[deleted]

1propionyl 5y ago

> I can't help but wonder if the root cause was HTTP request smuggling, or if changing package.json was enough. Maybe I'm just incredibly cynical from my experiences with the intersection of the JS ecosystem and security, but... ...I'd bet dimes to dollars it's the latter (just changing the package.json). My guess is they authenticate but don't actually scope the authentication properly, and no one noticed because no one thought to look. Of course, as we've seen in the past decade, there's so much inertia behind the JavaScript ecosystem that none of this is going to fundamentally change. It'll just take another decade or so for the ecosystem to reinvent all of the wheels and catch up to the rest of the space. And at that point it will probably be considered stuffy and "enterprise" and the new hotness unburdened from such concerns will repeat the cycle again.

mhio 5y ago
> to reinvent all of the wheels and catch up to the rest of the space. Which of the public package systems are the state of the art that should be replicated?
- thrashh 5y ago
  Java’s works really well. I think it makes other package managers look like a toy.
  - mhio 5y ago
    I assume you are referring to Apache Maven tooling (and compatible) and the pom repos, like Sonatype's Central Repo. PGP package signing is a huge plus. Is that a requirement for publishing? How many different repo's do you typically have to deal with in the average project? Would Sonatype react quickly to malware issue's like this in the repository? Have there been examples of similar package hijacking?
    - thrashh 5y ago
      It’s a requirement for the central repo if I recall. And the best past is the signature handling is a part of Java, not the package manager, so nothing needs to be re-invented. The default class loader checks the signatures at runtime as well. Typically you need 1-2 repositories, but often just 1. But if you’re an organization, you can set up your own repository very easily and use it to store private deps and to cache deps (which also allows you to lock binaries and work offline). Repo mirroring is super easy to set up. If you have an internal repo, you can just have your internal project use your own repo and your computer never has to directly reach outside the Internet for a package. Unlike other languages, the “central repo” and the package manager tooling are independent and package resolution is distributed. When you start a project, you choose your repos. I don’t know how quickly Sonatype would react personally but they are only default by de facto. Many packages are published on several repos and mirroring is a default feature of a lot of repo software. If Sonatype started screwing up, everyone could abandon them instantly, which forces them to be better.

snthd 5y ago

>How do we even mitigate against these types of supply-chain attacks, aside from disabling run-scripts, using lockfiles and carefully auditing the entire dependency tree on every module update? Don't trust the package distribution system - use public key crypto.

hn_throwaway_99 5y ago
Public key crypto doesn't help much if your private keys get stolen, which was essentially what happened with some of the recent hacked packages and which is why they're now starting to enforce 2FA.
- woodruffw 5y ago
  The longer term solution to this is public key signatures with an ephemeral key, rooted to some trusted identity source (e.g., a GitHub account with strong 2FA). There’s lots of work on that front coming out of the Open Source Security Foundation.
- onefuncman 5y ago
  are you really using private keys without a passphrase in 2021?

0xDEAFBEAD 5y ago

>How do we even mitigate against these types of supply-chain attacks I know HN is usually skeptical of anything cryptocurrency/blockchain related, and I am too. But as weird as it sounds, I think blockchain might actually be the solution here. The problem with dependency auditing is it's a lot of work. And it's also duplicate work. What you'd really like to know is whether the dependency you're considering has already been audited by someone you can trust. Ideally someone with skin in the game. Someone who stands to lose something if their audit is incorrect. Imagine a DeFi app that lets people buy and sell insurance for any commit hash of any open source library. The insurance pays out if a vulnerability in that commit hash is found. * As a library user, you want to buy insurance for every library you use. If you experience a security breach, the money you get from the insurance will help you deal with the aftermath. * As an independent hacker, you can make passive income by auditing libraries and selling insurance for the ones that seem solid. If you identify a security flaw, buy up insurance for that library, then publicize the flaw for a big payday. * A distributed, anonymous marketplace is actually valuable here, because it encourages "insider trading" on the part of people who work for offensive cybersecurity orgs. Suppose Jane Hacker is working with a criminal org that's successfully penetrated a particular library. Suppose Jane wants to leave her life of crime behind. All she has to do is buy up insurance for the library that was penetrated and then anonymously disclose the vulnerability. * Even if you never trade on the insurance marketplace yourself, you can get a general idea of how risky a library is by checking how much its insurance costs. (Insurance might be subject to price manipulation by offensive cybersecurity orgs, but independent hackers would be incentivized to identify and correct such price manipulation.) The fact that there is actual value here should give the creator a huge advantage over other "Web 3.0" crypto junk.

jschrf 5y ago
This is a pretty clever application of DeFi, thanks. DeSec? Can't help but wonder if there still would be incentive for lone wolves to slip backdoors and vulnerabilities into libraries though[0]. [0]: https://portswigger.net/daily-swig/smuggling-hidden-backdoors-into-javascript-with-homoglyphs-and-invisible-unicode-characters https://portswigger.net/daily-swig/smuggling-hidden-backdoor...

Silhouette 5y ago

I'm seriously considering moving to a workflow of installing dependencies in containers or VMs, auditing them there, and then perhaps commiting known safe snapshots of node_modules into my repos (YUCK). Horrible developer experience, but at least it'll help me sleep at night. I have had people tell me in discussions online, also entirely seriously, that running a package manager to install a dependency while developing is inherently dangerous and anyone who does it outside of a disposable sandboxed VM deserves everything they get. If the packages are inexplicably allowed to do arbitrary things with privileged access to the local system without warning at installation time then clearly the first part is correct, but victim-blaming hardly seems like a useful reaction to that danger.