26 ms·

Security issue related to the NPM registry

pelagicAustral 5y ago
I’m so glad Rails 7 is moving away from all the js circus. Good riddance
- throw_m239339 5y ago
  Rails 7 got rid of turbolinks and co?
  - pelagicAustral 5y ago
    Webpacker is gone. Turbolinks is now Turbo from The Hotwire stack and js libs are managed through Import Maps.
- christophilus 5y ago
  Eh. The last gemfile I looked at didn’t seem much better than my package.json. It’s amazing how many dependencies a legacy Rails app can pull in.
  - toomanybeersies 5y ago
    A big difference between the rubygems and npm ecosystems is that most gems tend to have a lot less dependencies themselves that JS packages do. Looking at a Rails project I've got open, it has ~100 gems in the Gemfile, and 200 gem dependencies overall. Compare that to one of the Typescript + React projects I work on, which has ~200 dependencies in package.json and 2300 packages in node_modules.
austinkhale 5y ago
Wow. Really bad news. Is there a way to automate looking at packages published pre September 2020 and compare the contents to publicly available repositories? It wouldn’t cover all possible malicious packages but it seems like it would be a start.
- captn3m0 5y ago
  Focusing on the most popular packages could make this feasible.
- seniorsassycat 5y ago
  Package content can't be compared to a repository. 1. npm doesn't record the repo, branch, or commit so it doesn't know what to compare with. 2. Published content is usually a transformation of the repo content -compiled, minified, bundled. You would have to run the same transformation on the repo source and it would have to be a deterministic build. npm could require that popular packages are published via GitHub actions, then it could strongly associate the published version with a source commit and the build that produced the artifact. This has some downsides like tie in to the GitHub ecosystem. Maybe that could be offset with sponsored builds?
  - silverwind 5y ago
    For packages without a build, they could just do a checkout on the repo and verify that the file hashes match the ones about to be published. Certainly not a complete solution but a good first step.
    - dane-pgp 5y ago
      A research paper "Investigating The Reproducibility of NPM Packages"[0] found that "Among the 3,390 versions of the 226 packages, only 2,087 versions are reproducible". (Coincidentally that paper was published in September 2020 too). There was an earlier project called "Trust But Verify"[1] which tried to detect discrepancies between published NPM packages and the corresponding (inferred) tag/commit in the source repository, but sadly it doesn't seem to have gained traction. Interestingly, the "Gold" standard of the Core Infrastructure Initiative (CII) Best Practices guide[2] is to have a reproducible build, but it is only "SUGGESTED that projects identify each release within their version control system", so presumably packages are free to indicate which commit they are built from in an ad hoc out-of-band way, which may not be amenable to automated third-party checking. [0] https://people.cs.vt.edu/nm8247/publications/icsme-camera-ready-2020.pdf https://people.cs.vt.edu/nm8247/publications/icsme-camera-re... [1] https://hackernoon.com/what-if-we-could-verify-npm-packages-c2a319cff758 https://hackernoon.com/what-if-we-could-verify-npm-packages-... [2] https://bestpractices.coreinfrastructure.org/en/criteria https://bestpractices.coreinfrastructure.org/en/criteria
julienb_sea 5y ago
Amongst other things this is why enterprises that use Node regularly have internal, private NPM registries with some delay behind public releases.
- TrueGeek 5y ago
  * should
- deckard1 5y ago
  This was common knowledge among Perl devs. Every place I've worked that used CPAN did this. No one was pulling down random versions of random packages off the interwebs like a lunatic. I was amazed NPM didn't even have checksums a few short years ago. Every security incident or fiasco (remember unpublished packages??) I've simply nodded and said: yup. That was obviously going to happen.
  - hmrr 5y ago
    Got to be honest I tended to use the distribution packages for Perl back in the day. That would have been Debian or FreeBSD ports back then. If the module was missing I would shrug it and make do. This cultural approach came from a place I work which was airgapped so we had a local package mirror server which was loaded from Debian CDs. Also no distracting internet or Google and you had only the man pages to work off. I really don’t like the culture of ”download any old shit off the internet, ram it in a container and throw it into production”. It keeps me awake. One day the whole thing will come crashing down and instantly spawn a costly magic enterprise solution which will cost a fortune just to mitigate that risk which doesn’t actually mitigate it all just allow the box to be ticked on a compliance form.
- symlinkk 5y ago
  How would that fix the issue? There’s no timeline here, it could have been vulnerable since day 1. All you’d be doing is inconveniencing your devs.
the8472 5y ago
> We determined that this vulnerability was due to inconsistent authorization checks and validation of data across several microservices that handle requests to the npm registry. In this architecture, the authorization service was properly validating user authorization to packages based on data passed in request URL paths Would 2FA have prevented that? If not then them loudly promoting 2FA before even mentioning this issue seems odd.
bob1029 5y ago
For those thinking "what can we possibly do?" The best answer I can provide is to nuke your entire software supply chain from orbit and start over with something new that doesn't require you to depend on potentially hundreds of arbitrary 3rd parties. Factor into this all of your tooling and infrastructure vendors as well. You might not like our particular brand of medicine, but we are finding massive success in these supply chain matters with a pure Microsoft stack: .NET core/5/6, GitHub, Azure, VS2022, Server 2019, et. al. We also technically use SQLite, but no one has ever attempted to probe us on that vendor, and it is incorporated well enough into the Microsoft death star (Microsoft.Data.Sqlite) to pass as yet another defensive armament at this point. We avoided shitty javascript web stacks by using technologies like Blazor, or just hand-rolling a little vanilla javascript when required (the horror, i know). The reason we like this path is that we now require virtually zero additional third party dependencies for building our B2B products. .NET6 covers nearly 100% of the functions we require. On top of this we have 1-2 convenience nugets like Dapper (StackOverflow, et. al.), but everything else is System.* or Microsoft.*. The only other 3rd party items we consume into the codebase come from vendors of our customers as part of our integration stack - typically in the form of WCF contracts or other codegen items. Now, we do hedge for the inevitable Microsoft framework churn by not getting too deep into certain pools like AspNetCore. For example, we have rolled all of our own authentication, logging & tracing middleware, since this is the area they seem most hellbent on changing over time. Certainly, Microsoft has, can, and will drop the ball, but they also have a very long track record available to build [dis]trust upon. For us, we went with the trust path. If our customers run us through the due diligence gauntlet (and they will - we're in the banking industry), we can produce a snarky ~1 item list of vendors that makes life much easier for everyone involved. No one has ever given us a hard time for doing business with Microsoft. Typically, everyone we work with is also to some degree. Is this bad? Maybe. I am ambivalent about the whole thing because of how much energy they have apparently put into the open source side of things. I have actually been able to contribute to their process on GitHub and watch it come out the other side into a final release I could use to correct a problem we were having.
- indymike 5y ago
  > finding massive success in these supply chain matters with a pure Microsoft stack You've also become 100% dependent on a sole source. > Microsoft has, can, and will drop the ball, but they also have a very long track record available to build [dis]trust upon. This.
raxxorrax 5y ago
The headline doesn't really fit the issue. content: The names of private packages were accidentally exposed for a little over a week. The flaw has been found and fixed.
- xPaw 5y ago
  There's more: > vulnerability that would allow an attacker to publish new versions of any npm package using an account without proper authorization. > We determined that this vulnerability was due to inconsistent authorization checks and validation of data across several microservices that handle requests to the npm registry. In this architecture, the authorization service was properly validating user authorization to packages based on data passed in request URL paths. 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.
  - brazzledazzle 5y ago
    This seems like a much bigger deal. Disclosing private names is not ideal but I think you have to assume your namespace and package names will leak at some point. In my opinion you should prepare for this well ahead of time by ensuring your organization uses a unique namespace/org that matches your internal/private namespace/org and squat on it. This will prevent a supply chain attack where they take a leaked namespace/package, register it and publish packages with higher versions.
- dang 5y ago
  Ok, we've replaced the title with the relevant subheading from the article. Thanks! The main article title is such corpspeak that it would go against the site guidelines to use it—that sort of corporate press release title is typically misleading, linkbait, or both. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=corporate%20press%20release%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor... https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - 5y ago
Amorymeltzer 5y ago
Previous discussion (from less than 24 hours ago): https://news.ycombinator.com/item?id=29234098 https://news.ycombinator.com/item?id=29234098 It came with the actual title, although arguably not the correct one.
- lucasyvas 5y ago
  Happy this got a second chance with a better title. I was in the one yesterday and did a double take a few times when I was reading it.
- andai 5y ago
  Quoting globalise83 from the other thread for summing it up perfectly: >"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." >"This vulnerability existed in the npm registry beyond the timeframe for which we have telemetry to determine whether it has ever been exploited maliciously. However, we can say with high confidence that this vulnerability has not been exploited maliciously during the timeframe for which we have available telemetry, which goes back to September 2020." >Any version of any npm package published before September 2020 could have been tampered with by anyone aware of that exploit and no-one would be any the wiser. That is pretty bad news.
  - eyelidlessness 5y ago
    No kidding. That’s bad enough news to warrant flagging any release by users not currently authorized to its respective package. At least internally for further analysis, but probably also for maintainers and users to at least have an opportunity to do their own threat assessment.
  - ComodoHacker 5y ago
    Looks like npm is a very troubled asset for MS, which could easily turn into liability.
emeraldd 5y ago
This feels like it should have wider ranging notice than it has ...
xpressvideoz 5y ago
> This briefly allowed consumers of replicate.npmjs.com to potentially identify the names of private packages When I was reading this, I thought the time frame would likely have been on a time scale of hours (or even minutes), > exposed between October 21 13:12:10Z UTC and October 29 15:51:00Z UTC But it's actually more than one week. Do we consider one week as "brief"?
- progbits 5y ago
  Right, and they don't even confirm who might have seen that list, except that "the data on this service is consumed by third-parties who may have replicated the data elsewhere". So basically consider all private package names as of that date forever public.
thayne 5y ago
> Transparency is key in maintaining the trust of our community. and yet a security incident where it was possible to publish any npm package without authentication is nine paragraphs down, and isn't alluded to at all in the page or section titles. I'm not sure that's entirely in the best spirit of transparency.
- emteycz 5y ago
  Wasn't it fixed years ago?
  - agency 5y ago
    I believe it says the issue the OP is alluding to was reported and fixed on Nov 2 - two weeks ago.
- jabbany 5y ago
  At least the details were there. It's not the best organization but they also didn't withhold anything.
  - croes 5y ago
    Hide it in the open isn't any better
- deleted 5y ago
  [deleted]
andreisbc 5y ago
This is dumb. Node and npm had years to solve this issue. Really disrespectful towards the entire ecosystem. I get it: open source, bla bla, but get your horses together and fix this already
- lucasmullens 5y ago
  > fix this already They did.
  - rmbyrro 5y ago
    I don't think all consequences are fixed. At this point, no one can assure the security of any npm package. What are they doing to restore confidence?
  - jay_kyburz 5y ago
    No, the fix is a batteries included standard library for JavaScript and the death of NPM. I have high hopes for Deno.
- bbrree66 5y ago
  Spoken by someone who has never worked on large complex systems before.
nfm 5y ago
Because this is buried in the post and people don't seem to be grokking it: > 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. They correctly authenticated the attacker and checked they were authorised to upload a new version of their own package, but a malicious payload allowed the attacker to then upload a new version of a completely unrelated package that they weren't authorised for. Ouch!
- ptx 5y ago
  Also: "This vulnerability existed in the npm registry beyond the timeframe for which we have telemetry to determine whether it has ever been exploited maliciously."
- 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.
    - 5y ago
deleted 5y ago
[deleted]
Rapzid 5y ago
NPM keeps me up at night. We have a CRA with over 300k node_modules files and over 1700 dependencies. Just one compromised dep and suddenly someone else is driving your AWS/Heroku CLI, stealing your credentials, and etc. There was malicious dep version just a few weeks ago on an agent string parser.
- ehutch79 5y ago
  How many of those dependancies could be replaced with a single line along the lines of if(number % 2 === 0){} ?
  - rectang 5y ago
    Even if you don't do that yourself, the culture is such that lots of NPM authors would rather add a dependency — thinking nothing of the additional security risk due to package takeover, nor the cost to downstream users who might actually want to audit their dependencies. The result is that instead of a dependency tree of consisting of a few packages or a few dozen, you end up with an unmanageable number like 1700 coming from who knows how many authors.
    - mediumdeviation 5y ago
      I would not completely blame it on culture. There are practical upsides to having a large number of packages - using a dependency instead of duplicating code means the resulting code is smaller, and splitting large packages up allows you to only include specific functions you need. This is important for the web, which is a lot more size sensitive. Nowadays tree shaking means that having a large package with lots of smaller function should work better, especially since adding an import incurs its own overhead, but a lot of older packages are stuck on the small packages model.
      - cj 5y ago
        I see "tree shaking" as a common defense (too often IMO) from people arguing over bloated code and dependencies. But in this case, tree shaking simply doesn't occur at all in this scenario since npm modules are installed on the backend, and tree shaking simply doesn't occur on the backend.
yabones 5y ago
Maybe it's just me, but the whole handling of this has been much more Microsoft-ey than usual. Is this a sign the MS culture is slowly seeping into GH?
- rmbyrro 5y ago
  They didn't even have telemetry data before Microsoft and this flaw has been sitting there probably since first day. If you look closely, MS might be improving it, but I don't think MS deserves credit nor blame here.
  - ptx 5y ago
    Hm. I assumed that the "telemetry" they were talking about was on their own servers (measuring uploads, downloads, etc.) but given that it was introduced after the Microsoft acquisition, is this telemetry actually client-side, like the telemetry[1] they put in the .NET Core dev tools? [1] https://github.com/dotnet/cli/issues/3093 https://github.com/dotnet/cli/issues/3093
- bbrree66 5y ago
  Confirmation bias.
SavantIdiot 5y ago
That second issue is the kind that scares me. Be it Rust, Python, Node... public package managers have always seemed like a huge risk to me with how we just assume nothing nefarious will be installed b/c hey, npm repo said 11,000,000 downloads per week, so it can't possibly be dangerous? I'm guilty of this: my latest Nuxt project has 47,000 dependencies. yarn audit helps, but can i even trust that since it is retroactive?
- ptx 5y ago
  Does that count duplicates, i.e. if a thousand different packages depend on exactly the same version of some package X, you get a thousand copies and count it a thousand times? Otherwise I can't fathom how it's possible for a project to have 47000 dependencies. I mean, my main Linux machine has all kinds of old garbage installed and still the package manager only lists 2000 packages.
  - SavantIdiot 5y ago
    Yes, it does include dupes, that's why I use yarn instead of npm. That being said, sometimes it is multiple versions of the same package, so yes-and-no.
- TillE 5y ago
  It's not really conceptually different from relying on third party libraries in any context. I haven't touched JavaScript since the late 90s, so I dunno what the hell's going on there, but in my C++ projects I typically have 10-20 dependencies (counting modularized Boost as one). They're either built by a custom script which includes the SHA256 of the tarballs it expects, or by a particular pinned commit of vcpkg which likewise uses SHA512 to verify its downloads. I generally only update these when I need a new feature or bug fix, which means I'm unlikely to get bitten by any temporary security compromise. If the "particular checkout of vcpkg" type of approach is impossible with other package managers, that's unfortunate.
  - cnorthwood 5y ago
    Fortunately this is the default in JavaScript world with both Yarn and NPM supporting lockfiles which have hashes and pinned versions. The problem is the sheer volume of dependencies and transient dependencies which makes it hard to reliably audit those, as updating one thing can cause a lot of work.
TedDoesntTalk 5y ago
> we can say with high confidence that this vulnerability has not been exploited maliciously during the timeframe for which we have available telemetry, which goes back to September 2020. Just over a year.
- stingraycharles 5y ago
  Still is a good indicator, as you can assume that if some bug was exploited a long time ago, it’s very likely to continue to be exploited in the present / until it is fixed.
  - dane-pgp 5y ago
    Also, if an attacker exploited this bug to upload a patched version N+1 after a legitimate version N was published, there's a good chance that the legitimate developer would eventually also try to release version N+1, and NPM would report the clash to them. An attacker would have to get very lucky, exploiting this bug just up until the point when the logs started (which they had no way to predict), and to target only packages which have either never been updated since, or which were followed by a minor/major package update (not a patch).
    - rmbyrro 5y ago
      I'd say npm itself probably use npm packages internally? What if they were already compromised through this flaw to avoid these red flags from popping up? The attacker might be monitoring their logs, selectively silencing version clashes. Heck, it's even possible they now have backdoor access to do whatever they want to any package. I know it's cynical thinking, but this vulnerability was unbelievable and the way they're handling is definitely not reassuring, from my personal standpoint.
- dpifke 5y ago
  September 2020 is when their logs start. The preceding sentence says they have no idea if it was exploited before the start of their logfiles: "This vulnerability existed in the npm registry beyond the timeframe for which we have telemetry to determine whether it has ever been exploited maliciously." So packages uploaded after September 2020 are probably fine. Before that: ¯\_(ツ)_/¯ If NPM/Github were being responsible here, they would make package owners re-upload clean copies of anything which hasn't been touched since before the start of their audit logs.
Mikeb85 5y ago
And people say Deno's model isn't secure SMH...
- gpmcadam 5y ago
  I've been semi-interested in Deno since it was announced and followed some discussions but I've never considered moving from Node to Deno. Can you elaborate on what Deno does that makes it more secure than NPM here? I'm guessing it doesn't rely on a centralised repo of any kind?
  - schemescape 5y ago
    1. Deno comes with a standard library that has been audited by the Deno maintainers 2. The Deno runtime runs with limited permissions by default, so you have to allow access to file system locations or network hosts explicitly Now, the repository part is arguably not as big of an improvement (if at all). There’s a central repository for third party modules. One nice aspect is it just mirrors code, so you can see what you’re getting before downloading (and, in NPM’s case, running install scripts, if you forgot —-ignore-scripts). Deno also suggests using CDNs, but they often just host NPM modules that have been transformed into ES modules. That seems worse than NPM, in my opinion.
  - Mikeb85 5y ago
    It's not necessarily more or less secure. You load libraries by simply linking ES Modules from your local files or the internet; there's no central repo, you link the exact URL. So it's as secure or insecure as your source. Some people say it's insecure because, well, if you get your modules from a compromised site it is. However recent events have shown there's also plenty of danger with centralized repos as well. The advantage to Deno's approach is it encourages using CDNs, which allow that code to load quicker especially if you're using edge functions or something like CloudFlare workers. It also requires you to be super explicit about where the code's coming from. The negative is that many people will download code from dodgy websites then complain later.
    - jhgb 5y ago
firebaze 5y ago
This is probably the worst security problem ever in the JS ecosystem. Any npm package could be corrupted, and we wouldn't even know it if the original maintainers don't pay attention to new releases anymore. Still some people argue if this deserves its own CVE.
- jhugo 5y ago
  That's just... not what CVEs are for. It's not a matter of how serious the issue is. CVEs are for distributed software, not for services.
- marcus_holmes 5y ago
  the other one that gives me the screaming heeby-jeebies is the wave of maintainers that are going to get bored of being abused for no pay and sell their maintainer rights to malware authors. Or to seemingly-nice people who will then sell it to malware authors. Though this does give them a shortcut.No need to bribe some aging, disenchanted nerd to sell their soul when you can just impersonate them.
SirensOfTitan 5y ago
How is everyone dealing with this? I have no idea how to begin auditing our dependencies for an issue like this. GitHub really comes across looking like total garbage here with this blog post. Security issues shouldn’t be hidden like this. This is dishonest and irresponsible.
- Fordec 5y ago
  By getting off NPM entirely and new projects internally banned from using it from day ome. Luckily all the backend stuff isn't in javascript which is 80% of the battle.
  - hmrr 5y ago
    Genuine question as I quite frankly stay the hell away from it: Can malicious NPM packages compromise your build infrastructure?
    - christophilus 5y ago
      NPM modules can run arbitrary code at install time using the privileges of the user doing the install. So, whatever malicious actions such a user could take, an NPM module could take.
      - dane-pgp 5y ago
        Fortunately there is an option (--ignore-scripts) that prevents all code from running at install time, and there are solutions if specific scripts do need to be run. Such examples are so rare, though, that there is an active proposal to make this option the default. https://github.com/npm/rfcs/pull/488 https://github.com/npm/rfcs/pull/488
        mhio 5y ago
        If you don't trust the scripts, you don't trust the code. Although this limits one attack vector, the issue is just kicked down the road to `import`/`require` time.
tdiff 5y ago
Ironically, lack of proper packet management in c++ saved c++ devs from the risk of being able to use random package with ease.
- hmrr 5y ago
  Unfortunately that left them with the motivation to write their own bus sized holes instead!
  - bruce343434 5y ago
    The greatest programming fallacy is blindly trusting someone else to have correctly invented "the wheel" before. Shockingly few people really know what they're doing.
    - dane-pgp 5y ago
      > Shockingly few people really know what they're doing. Unfortunately that includes the people who think their NIH wheel will be much better than the existing one. In fact, the Dunning-Kruger effect would suggest that people who don't know what they're doing are disproportionately likely to be in the latter group.
tdiff 5y ago
Does the kind of flippant nature of packet management in js ecosystem origins in the idea of js use cases being something "not so important"? And when js expanded on backend the package management approach was inherited?
- mb7733 5y ago
  There was no package manager for JS before JS began to become popular on the backend with the release of node. NPM stands for node package manager after all.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
francasso 5y ago
This is so bad, and the implications are so huge, that the solution will be to pray and forget it ever happened.
alanhaha 5y ago
Well, it may not be directly related with this issue, I think that it's going to be harder for individual developer. More and more things are needed to be considered. Maybe at some point, only large enterprise can afford to do proper development.
- dane-pgp 5y ago
  I worry about these second-order effects too. Is the eventual aim that 2FA will tie packages to people's government IDs (either via their phone number, or some sort of biometric system)? Before we start gatekeeping Free Software development with a "trusted developer" system, we need to make sure that this system supports pseudonymous identities, so that people don't have to dox themselves (even to their own government) to be able to make contributions.
lucasyvas 5y ago
Could we not move to a strategy where authors have to cryptographically sign packages with their own package-specific private key when publishing them? You then have to manually add the public key for a given package to your package.json so it can verify a tarball came from the author/source you expect. This won't solve problems where the author is malicious, but it helps other cases.
- yrro 5y ago
  > Could we not move to a strategy where authors have to cryptographically sign packages with their own package-specific private key when publishing them? I'm sorry the NPM ecosystem doesn't do this already? Good god!
  - lucasyvas 5y ago
    In NPM's minor defence, I don't know of any contemporary registry that does. If I had to guess, the registry operator probably either sees this as friction to onboarding, or if they do support signatures, they'd probably rather sign it themselves. These are both stupid. The author should be responsible for signing, the registry should never see the key, and the registry should require 2FA to log in and set the public key for a package for users to discover.
jeswin 5y ago
This is a problem. But comparatively not many high-profile break-ins have been due to npm (in spite of its massive popularity). If you picked Node, common best practices need to be followed for production: 1) Thoroughly vet dependencies you bring in. Pin to exact patch versions in package.json. npm-shrinkwrap. 2) Add code in tree when possible (prefer StackOverflow snippets over npm). 3) Prefer light modules with fewer features. Always check their dependencies. There will still be some vulnerabilities from time to time. But if you've been somewhat careful, most of them tend to happen among devDependencies, which is usually safe. To go further, cut out devDependencies too; for example use a shell script along with esbuild instead of bringing in a heavy-duty bundler.
- speedgoose 5y ago
  Be careful with stackoverflow though. Some highly upvoted answers are sometimes broken or even dangerous. But reading the tiny comments and other answers is usually enough to identify a better solution.
- journey_16162 5y ago
  I would say keep an eye on dev dependencies which are a part of the build process. Malicious code there could easily append malicious code to the production build, even if you have a deployment server setup. This is just as dangerous as a malicious production dependency.
pyjug 5y ago
> In this architecture, the authorization service was properly validating user authorization to packages based on data passed in request URL paths. 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 I have a similar story . At my old job, we had a web socket gateway that authenticated using JWTs , then hit an internal service to request REST resources. The issue was that it didn’t actually validate the requested REST resource URL; a malicious user could authenticate as themselves but request a resource for any other account. I found it as I was getting up to speed on the code base, having recently switched teams. Funnily enough, nobody on the team really understood the vulnerability - the EM marked it low priority and wanted the team to work on other things. I had to essentially go directly to the security team and convince them it was a sev 1. I sometimes wonder if it’s easier to just report security issues as an outsider through the bug bounty program; internal reports don’t seem to get taken as seriously.
BarryMilo 5y ago
Am I the only to just say "fuck npm"? I've been saying it for a long time, but things like this confirm it. Don't get me wrong, everyone has security flaws and zero days, but I feel like npm has been mismanaged since its inception. I'm glad I'm out of the web dev game, I would dread having to rely on this walking security disaster.
- mikestaub 5y ago
  The leftpad fiasco stunned me. Such a gaping security flaw from the very beginning made me question everything.
dorianmariefr 5y ago
NPM should support Web Authentication API (e.g. security keys, touch ID, etc.) for 2-factor authentication.
- gpmcadam 5y ago
  how would 2fa work with automated build systems?
  - dorianmariefr 5y ago
    the main use case is publishing packages. and automated systems could have API keys
lrvick 5y ago
Linux distros and Mobile Apps rarely see these issues for one simple reason: packages must all be signed by a vetted maintainer before they are ever submitted and every client has the ability to verify signatures came from approved maintainers who hold the signing keys. Phishing, bad 2FA, and vulnerabilities of the central repo upload path itself all go away with this simple tactic used by all sane package managers. Someone PRed this exact same effective strategy to NPM in 2013, and it was refused even as -optional-. https://github.com/npm/npm/pull/4016#issuecomment-76316744 https://github.com/npm/npm/pull/4016#issuecomment-76316744 NPM team members have ignorantly maintained that hashing packages is good enough. They insist on being a central authority for all packages with no method to strongly authenticate authors and this negligence has repeatedly endangered millions. Meanwhile Debian and other community Linux distros maintain, sign, and distribute hundreds of popular NodeJS packages themselves now because they realize it would be negligent to risk having NPM in their supply chain.
- xvector 5y ago
  I can't think of any other reason than incompetence for not requiring signed packages.

I’m so glad Rails 7 is moving away from all the js circus. Good riddance

throw_m239339 5y ago
Rails 7 got rid of turbolinks and co?
- pelagicAustral 5y ago
  Webpacker is gone. Turbolinks is now Turbo from The Hotwire stack and js libs are managed through Import Maps.
christophilus 5y ago
Eh. The last gemfile I looked at didn’t seem much better than my package.json. It’s amazing how many dependencies a legacy Rails app can pull in.
- toomanybeersies 5y ago
  A big difference between the rubygems and npm ecosystems is that most gems tend to have a lot less dependencies themselves that JS packages do. Looking at a Rails project I've got open, it has ~100 gems in the Gemfile, and 200 gem dependencies overall. Compare that to one of the Typescript + React projects I work on, which has ~200 dependencies in package.json and 2300 packages in node_modules.

Wow. Really bad news. Is there a way to automate looking at packages published pre September 2020 and compare the contents to publicly available repositories? It wouldn’t cover all possible malicious packages but it seems like it would be a start.

captn3m0 5y ago
Focusing on the most popular packages could make this feasible.
seniorsassycat 5y ago
Package content can't be compared to a repository. 1. npm doesn't record the repo, branch, or commit so it doesn't know what to compare with. 2. Published content is usually a transformation of the repo content -compiled, minified, bundled. You would have to run the same transformation on the repo source and it would have to be a deterministic build. npm could require that popular packages are published via GitHub actions, then it could strongly associate the published version with a source commit and the build that produced the artifact. This has some downsides like tie in to the GitHub ecosystem. Maybe that could be offset with sponsored builds?
- silverwind 5y ago
  For packages without a build, they could just do a checkout on the repo and verify that the file hashes match the ones about to be published. Certainly not a complete solution but a good first step.
  - dane-pgp 5y ago
    A research paper "Investigating The Reproducibility of NPM Packages"[0] found that "Among the 3,390 versions of the 226 packages, only 2,087 versions are reproducible". (Coincidentally that paper was published in September 2020 too). There was an earlier project called "Trust But Verify"[1] which tried to detect discrepancies between published NPM packages and the corresponding (inferred) tag/commit in the source repository, but sadly it doesn't seem to have gained traction. Interestingly, the "Gold" standard of the Core Infrastructure Initiative (CII) Best Practices guide[2] is to have a reproducible build, but it is only "SUGGESTED that projects identify each release within their version control system", so presumably packages are free to indicate which commit they are built from in an ad hoc out-of-band way, which may not be amenable to automated third-party checking. [0] https://people.cs.vt.edu/nm8247/publications/icsme-camera-ready-2020.pdf https://people.cs.vt.edu/nm8247/publications/icsme-camera-re... [1] https://hackernoon.com/what-if-we-could-verify-npm-packages-c2a319cff758 https://hackernoon.com/what-if-we-could-verify-npm-packages-... [2] https://bestpractices.coreinfrastructure.org/en/criteria https://bestpractices.coreinfrastructure.org/en/criteria

julienb_sea 5y ago

Amongst other things this is why enterprises that use Node regularly have internal, private NPM registries with some delay behind public releases.

TrueGeek 5y ago
* should
deckard1 5y ago
This was common knowledge among Perl devs. Every place I've worked that used CPAN did this. No one was pulling down random versions of random packages off the interwebs like a lunatic. I was amazed NPM didn't even have checksums a few short years ago. Every security incident or fiasco (remember unpublished packages??) I've simply nodded and said: yup. That was obviously going to happen.
- hmrr 5y ago
  Got to be honest I tended to use the distribution packages for Perl back in the day. That would have been Debian or FreeBSD ports back then. If the module was missing I would shrug it and make do. This cultural approach came from a place I work which was airgapped so we had a local package mirror server which was loaded from Debian CDs. Also no distracting internet or Google and you had only the man pages to work off. I really don’t like the culture of ”download any old shit off the internet, ram it in a container and throw it into production”. It keeps me awake. One day the whole thing will come crashing down and instantly spawn a costly magic enterprise solution which will cost a fortune just to mitigate that risk which doesn’t actually mitigate it all just allow the box to be ticked on a compliance form.
symlinkk 5y ago
How would that fix the issue? There’s no timeline here, it could have been vulnerable since day 1. All you’d be doing is inconveniencing your devs.

the8472 5y ago

> We determined that this vulnerability was due to inconsistent authorization checks and validation of data across several microservices that handle requests to the npm registry. In this architecture, the authorization service was properly validating user authorization to packages based on data passed in request URL paths Would 2FA have prevented that? If not then them loudly promoting 2FA before even mentioning this issue seems odd.

bob1029 5y ago

For those thinking "what can we possibly do?" The best answer I can provide is to nuke your entire software supply chain from orbit and start over with something new that doesn't require you to depend on potentially hundreds of arbitrary 3rd parties. Factor into this all of your tooling and infrastructure vendors as well. You might not like our particular brand of medicine, but we are finding massive success in these supply chain matters with a pure Microsoft stack: .NET core/5/6, GitHub, Azure, VS2022, Server 2019, et. al. We also technically use SQLite, but no one has ever attempted to probe us on that vendor, and it is incorporated well enough into the Microsoft death star (Microsoft.Data.Sqlite) to pass as yet another defensive armament at this point. We avoided shitty javascript web stacks by using technologies like Blazor, or just hand-rolling a little vanilla javascript when required (the horror, i know). The reason we like this path is that we now require virtually zero additional third party dependencies for building our B2B products. .NET6 covers nearly 100% of the functions we require. On top of this we have 1-2 convenience nugets like Dapper (StackOverflow, et. al.), but everything else is System.* or Microsoft.*. The only other 3rd party items we consume into the codebase come from vendors of our customers as part of our integration stack - typically in the form of WCF contracts or other codegen items. Now, we do hedge for the inevitable Microsoft framework churn by not getting too deep into certain pools like AspNetCore. For example, we have rolled all of our own authentication, logging & tracing middleware, since this is the area they seem most hellbent on changing over time. Certainly, Microsoft has, can, and will drop the ball, but they also have a very long track record available to build [dis]trust upon. For us, we went with the trust path. If our customers run us through the due diligence gauntlet (and they will - we're in the banking industry), we can produce a snarky ~1 item list of vendors that makes life much easier for everyone involved. No one has ever given us a hard time for doing business with Microsoft. Typically, everyone we work with is also to some degree. Is this bad? Maybe. I am ambivalent about the whole thing because of how much energy they have apparently put into the open source side of things. I have actually been able to contribute to their process on GitHub and watch it come out the other side into a final release I could use to correct a problem we were having.

indymike 5y ago
> finding massive success in these supply chain matters with a pure Microsoft stack You've also become 100% dependent on a sole source. > Microsoft has, can, and will drop the ball, but they also have a very long track record available to build [dis]trust upon. This.

raxxorrax 5y ago

The headline doesn't really fit the issue. content: The names of private packages were accidentally exposed for a little over a week. The flaw has been found and fixed.

xPaw 5y ago
There's more: > vulnerability that would allow an attacker to publish new versions of any npm package using an account without proper authorization. > We determined that this vulnerability was due to inconsistent authorization checks and validation of data across several microservices that handle requests to the npm registry. In this architecture, the authorization service was properly validating user authorization to packages based on data passed in request URL paths. 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.
- brazzledazzle 5y ago
  This seems like a much bigger deal. Disclosing private names is not ideal but I think you have to assume your namespace and package names will leak at some point. In my opinion you should prepare for this well ahead of time by ensuring your organization uses a unique namespace/org that matches your internal/private namespace/org and squat on it. This will prevent a supply chain attack where they take a leaked namespace/package, register it and publish packages with higher versions.
dang 5y ago
Ok, we've replaced the title with the relevant subheading from the article. Thanks! The main article title is such corpspeak that it would go against the site guidelines to use it—that sort of corporate press release title is typically misleading, linkbait, or both. https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=corporate%20press%20release%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor... https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- 5y ago

Amorymeltzer 5y ago

Previous discussion (from less than 24 hours ago): https://news.ycombinator.com/item?id=29234098 https://news.ycombinator.com/item?id=29234098 It came with the actual title, although arguably not the correct one.

lucasyvas 5y ago
Happy this got a second chance with a better title. I was in the one yesterday and did a double take a few times when I was reading it.
andai 5y ago
Quoting globalise83 from the other thread for summing it up perfectly: >"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." >"This vulnerability existed in the npm registry beyond the timeframe for which we have telemetry to determine whether it has ever been exploited maliciously. However, we can say with high confidence that this vulnerability has not been exploited maliciously during the timeframe for which we have available telemetry, which goes back to September 2020." >Any version of any npm package published before September 2020 could have been tampered with by anyone aware of that exploit and no-one would be any the wiser. That is pretty bad news.
- eyelidlessness 5y ago
  No kidding. That’s bad enough news to warrant flagging any release by users not currently authorized to its respective package. At least internally for further analysis, but probably also for maintainers and users to at least have an opportunity to do their own threat assessment.
- ComodoHacker 5y ago
  Looks like npm is a very troubled asset for MS, which could easily turn into liability.

emeraldd 5y ago

This feels like it should have wider ranging notice than it has ...

xpressvideoz 5y ago

> This briefly allowed consumers of replicate.npmjs.com to potentially identify the names of private packages When I was reading this, I thought the time frame would likely have been on a time scale of hours (or even minutes), > exposed between October 21 13:12:10Z UTC and October 29 15:51:00Z UTC But it's actually more than one week. Do we consider one week as "brief"?

progbits 5y ago
Right, and they don't even confirm who might have seen that list, except that "the data on this service is consumed by third-parties who may have replicated the data elsewhere". So basically consider all private package names as of that date forever public.

thayne 5y ago

> Transparency is key in maintaining the trust of our community. and yet a security incident where it was possible to publish any npm package without authentication is nine paragraphs down, and isn't alluded to at all in the page or section titles. I'm not sure that's entirely in the best spirit of transparency.

emteycz 5y ago
Wasn't it fixed years ago?
- agency 5y ago
  I believe it says the issue the OP is alluding to was reported and fixed on Nov 2 - two weeks ago.
jabbany 5y ago
At least the details were there. It's not the best organization but they also didn't withhold anything.
- croes 5y ago
  Hide it in the open isn't any better
deleted 5y ago
[deleted]

andreisbc 5y ago

This is dumb. Node and npm had years to solve this issue. Really disrespectful towards the entire ecosystem. I get it: open source, bla bla, but get your horses together and fix this already

lucasmullens 5y ago
> fix this already They did.
- rmbyrro 5y ago
  I don't think all consequences are fixed. At this point, no one can assure the security of any npm package. What are they doing to restore confidence?
- jay_kyburz 5y ago
  No, the fix is a batteries included standard library for JavaScript and the death of NPM. I have high hopes for Deno.
bbrree66 5y ago
Spoken by someone who has never worked on large complex systems before.

nfm 5y ago

Because this is buried in the post and people don't seem to be grokking it: > 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. They correctly authenticated the attacker and checked they were authorised to upload a new version of their own package, but a malicious payload allowed the attacker to then upload a new version of a completely unrelated package that they weren't authorised for. Ouch!

ptx 5y ago
Also: "This vulnerability existed in the npm registry beyond the timeframe for which we have telemetry to determine whether it has ever been exploited maliciously."
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.
  - 5y ago

deleted 5y ago

[deleted]

Rapzid 5y ago

NPM keeps me up at night. We have a CRA with over 300k node_modules files and over 1700 dependencies. Just one compromised dep and suddenly someone else is driving your AWS/Heroku CLI, stealing your credentials, and etc. There was malicious dep version just a few weeks ago on an agent string parser.

ehutch79 5y ago
How many of those dependancies could be replaced with a single line along the lines of if(number % 2 === 0){} ?
- rectang 5y ago
  Even if you don't do that yourself, the culture is such that lots of NPM authors would rather add a dependency — thinking nothing of the additional security risk due to package takeover, nor the cost to downstream users who might actually want to audit their dependencies. The result is that instead of a dependency tree of consisting of a few packages or a few dozen, you end up with an unmanageable number like 1700 coming from who knows how many authors.
  - mediumdeviation 5y ago
    I would not completely blame it on culture. There are practical upsides to having a large number of packages - using a dependency instead of duplicating code means the resulting code is smaller, and splitting large packages up allows you to only include specific functions you need. This is important for the web, which is a lot more size sensitive. Nowadays tree shaking means that having a large package with lots of smaller function should work better, especially since adding an import incurs its own overhead, but a lot of older packages are stuck on the small packages model.
    - cj 5y ago
      I see "tree shaking" as a common defense (too often IMO) from people arguing over bloated code and dependencies. But in this case, tree shaking simply doesn't occur at all in this scenario since npm modules are installed on the backend, and tree shaking simply doesn't occur on the backend.

yabones 5y ago

Maybe it's just me, but the whole handling of this has been much more Microsoft-ey than usual. Is this a sign the MS culture is slowly seeping into GH?

rmbyrro 5y ago
They didn't even have telemetry data before Microsoft and this flaw has been sitting there probably since first day. If you look closely, MS might be improving it, but I don't think MS deserves credit nor blame here.
- ptx 5y ago
  Hm. I assumed that the "telemetry" they were talking about was on their own servers (measuring uploads, downloads, etc.) but given that it was introduced after the Microsoft acquisition, is this telemetry actually client-side, like the telemetry[1] they put in the .NET Core dev tools? [1] https://github.com/dotnet/cli/issues/3093 https://github.com/dotnet/cli/issues/3093
bbrree66 5y ago
Confirmation bias.

SavantIdiot 5y ago

That second issue is the kind that scares me. Be it Rust, Python, Node... public package managers have always seemed like a huge risk to me with how we just assume nothing nefarious will be installed b/c hey, npm repo said 11,000,000 downloads per week, so it can't possibly be dangerous? I'm guilty of this: my latest Nuxt project has 47,000 dependencies. yarn audit helps, but can i even trust that since it is retroactive?

ptx 5y ago
Does that count duplicates, i.e. if a thousand different packages depend on exactly the same version of some package X, you get a thousand copies and count it a thousand times? Otherwise I can't fathom how it's possible for a project to have 47000 dependencies. I mean, my main Linux machine has all kinds of old garbage installed and still the package manager only lists 2000 packages.
- SavantIdiot 5y ago
  Yes, it does include dupes, that's why I use yarn instead of npm. That being said, sometimes it is multiple versions of the same package, so yes-and-no.
TillE 5y ago
It's not really conceptually different from relying on third party libraries in any context. I haven't touched JavaScript since the late 90s, so I dunno what the hell's going on there, but in my C++ projects I typically have 10-20 dependencies (counting modularized Boost as one). They're either built by a custom script which includes the SHA256 of the tarballs it expects, or by a particular pinned commit of vcpkg which likewise uses SHA512 to verify its downloads. I generally only update these when I need a new feature or bug fix, which means I'm unlikely to get bitten by any temporary security compromise. If the "particular checkout of vcpkg" type of approach is impossible with other package managers, that's unfortunate.
- cnorthwood 5y ago
  Fortunately this is the default in JavaScript world with both Yarn and NPM supporting lockfiles which have hashes and pinned versions. The problem is the sheer volume of dependencies and transient dependencies which makes it hard to reliably audit those, as updating one thing can cause a lot of work.

TedDoesntTalk 5y ago

> we can say with high confidence that this vulnerability has not been exploited maliciously during the timeframe for which we have available telemetry, which goes back to September 2020. Just over a year.

stingraycharles 5y ago
Still is a good indicator, as you can assume that if some bug was exploited a long time ago, it’s very likely to continue to be exploited in the present / until it is fixed.
- dane-pgp 5y ago
  Also, if an attacker exploited this bug to upload a patched version N+1 after a legitimate version N was published, there's a good chance that the legitimate developer would eventually also try to release version N+1, and NPM would report the clash to them. An attacker would have to get very lucky, exploiting this bug just up until the point when the logs started (which they had no way to predict), and to target only packages which have either never been updated since, or which were followed by a minor/major package update (not a patch).
  - rmbyrro 5y ago
    I'd say npm itself probably use npm packages internally? What if they were already compromised through this flaw to avoid these red flags from popping up? The attacker might be monitoring their logs, selectively silencing version clashes. Heck, it's even possible they now have backdoor access to do whatever they want to any package. I know it's cynical thinking, but this vulnerability was unbelievable and the way they're handling is definitely not reassuring, from my personal standpoint.
dpifke 5y ago
September 2020 is when their logs start. The preceding sentence says they have no idea if it was exploited before the start of their logfiles: "This vulnerability existed in the npm registry beyond the timeframe for which we have telemetry to determine whether it has ever been exploited maliciously." So packages uploaded after September 2020 are probably fine. Before that: ¯\_(ツ)_/¯ If NPM/Github were being responsible here, they would make package owners re-upload clean copies of anything which hasn't been touched since before the start of their audit logs.

Mikeb85 5y ago

And people say Deno's model isn't secure SMH...

gpmcadam 5y ago
I've been semi-interested in Deno since it was announced and followed some discussions but I've never considered moving from Node to Deno. Can you elaborate on what Deno does that makes it more secure than NPM here? I'm guessing it doesn't rely on a centralised repo of any kind?
- schemescape 5y ago
  1. Deno comes with a standard library that has been audited by the Deno maintainers 2. The Deno runtime runs with limited permissions by default, so you have to allow access to file system locations or network hosts explicitly Now, the repository part is arguably not as big of an improvement (if at all). There’s a central repository for third party modules. One nice aspect is it just mirrors code, so you can see what you’re getting before downloading (and, in NPM’s case, running install scripts, if you forgot —-ignore-scripts). Deno also suggests using CDNs, but they often just host NPM modules that have been transformed into ES modules. That seems worse than NPM, in my opinion.
- Mikeb85 5y ago
  It's not necessarily more or less secure. You load libraries by simply linking ES Modules from your local files or the internet; there's no central repo, you link the exact URL. So it's as secure or insecure as your source. Some people say it's insecure because, well, if you get your modules from a compromised site it is. However recent events have shown there's also plenty of danger with centralized repos as well. The advantage to Deno's approach is it encourages using CDNs, which allow that code to load quicker especially if you're using edge functions or something like CloudFlare workers. It also requires you to be super explicit about where the code's coming from. The negative is that many people will download code from dodgy websites then complain later.
  - jhgb 5y ago

firebaze 5y ago

This is probably the worst security problem ever in the JS ecosystem. Any npm package could be corrupted, and we wouldn't even know it if the original maintainers don't pay attention to new releases anymore. Still some people argue if this deserves its own CVE.

jhugo 5y ago
That's just... not what CVEs are for. It's not a matter of how serious the issue is. CVEs are for distributed software, not for services.
marcus_holmes 5y ago
the other one that gives me the screaming heeby-jeebies is the wave of maintainers that are going to get bored of being abused for no pay and sell their maintainer rights to malware authors. Or to seemingly-nice people who will then sell it to malware authors. Though this does give them a shortcut.No need to bribe some aging, disenchanted nerd to sell their soul when you can just impersonate them.

SirensOfTitan 5y ago

How is everyone dealing with this? I have no idea how to begin auditing our dependencies for an issue like this. GitHub really comes across looking like total garbage here with this blog post. Security issues shouldn’t be hidden like this. This is dishonest and irresponsible.

Fordec 5y ago
By getting off NPM entirely and new projects internally banned from using it from day ome. Luckily all the backend stuff isn't in javascript which is 80% of the battle.
- hmrr 5y ago
  Genuine question as I quite frankly stay the hell away from it: Can malicious NPM packages compromise your build infrastructure?
  - christophilus 5y ago
    NPM modules can run arbitrary code at install time using the privileges of the user doing the install. So, whatever malicious actions such a user could take, an NPM module could take.
    - dane-pgp 5y ago
      Fortunately there is an option (--ignore-scripts) that prevents all code from running at install time, and there are solutions if specific scripts do need to be run. Such examples are so rare, though, that there is an active proposal to make this option the default. https://github.com/npm/rfcs/pull/488 https://github.com/npm/rfcs/pull/488
      - mhio 5y ago
        If you don't trust the scripts, you don't trust the code. Although this limits one attack vector, the issue is just kicked down the road to `import`/`require` time.

tdiff 5y ago

Ironically, lack of proper packet management in c++ saved c++ devs from the risk of being able to use random package with ease.

hmrr 5y ago
Unfortunately that left them with the motivation to write their own bus sized holes instead!
- bruce343434 5y ago
  The greatest programming fallacy is blindly trusting someone else to have correctly invented "the wheel" before. Shockingly few people really know what they're doing.
  - dane-pgp 5y ago
    > Shockingly few people really know what they're doing. Unfortunately that includes the people who think their NIH wheel will be much better than the existing one. In fact, the Dunning-Kruger effect would suggest that people who don't know what they're doing are disproportionately likely to be in the latter group.

tdiff 5y ago

Does the kind of flippant nature of packet management in js ecosystem origins in the idea of js use cases being something "not so important"? And when js expanded on backend the package management approach was inherited?

mb7733 5y ago
There was no package manager for JS before JS began to become popular on the backend with the release of node. NPM stands for node package manager after all.

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]

francasso 5y ago

This is so bad, and the implications are so huge, that the solution will be to pray and forget it ever happened.

alanhaha 5y ago

Well, it may not be directly related with this issue, I think that it's going to be harder for individual developer. More and more things are needed to be considered. Maybe at some point, only large enterprise can afford to do proper development.

dane-pgp 5y ago
I worry about these second-order effects too. Is the eventual aim that 2FA will tie packages to people's government IDs (either via their phone number, or some sort of biometric system)? Before we start gatekeeping Free Software development with a "trusted developer" system, we need to make sure that this system supports pseudonymous identities, so that people don't have to dox themselves (even to their own government) to be able to make contributions.

lucasyvas 5y ago

Could we not move to a strategy where authors have to cryptographically sign packages with their own package-specific private key when publishing them? You then have to manually add the public key for a given package to your package.json so it can verify a tarball came from the author/source you expect. This won't solve problems where the author is malicious, but it helps other cases.

yrro 5y ago
> Could we not move to a strategy where authors have to cryptographically sign packages with their own package-specific private key when publishing them? I'm sorry the NPM ecosystem doesn't do this already? Good god!
- lucasyvas 5y ago
  In NPM's minor defence, I don't know of any contemporary registry that does. If I had to guess, the registry operator probably either sees this as friction to onboarding, or if they do support signatures, they'd probably rather sign it themselves. These are both stupid. The author should be responsible for signing, the registry should never see the key, and the registry should require 2FA to log in and set the public key for a package for users to discover.

jeswin 5y ago

This is a problem. But comparatively not many high-profile break-ins have been due to npm (in spite of its massive popularity). If you picked Node, common best practices need to be followed for production: 1) Thoroughly vet dependencies you bring in. Pin to exact patch versions in package.json. npm-shrinkwrap. 2) Add code in tree when possible (prefer StackOverflow snippets over npm). 3) Prefer light modules with fewer features. Always check their dependencies. There will still be some vulnerabilities from time to time. But if you've been somewhat careful, most of them tend to happen among devDependencies, which is usually safe. To go further, cut out devDependencies too; for example use a shell script along with esbuild instead of bringing in a heavy-duty bundler.

speedgoose 5y ago
Be careful with stackoverflow though. Some highly upvoted answers are sometimes broken or even dangerous. But reading the tiny comments and other answers is usually enough to identify a better solution.
journey_16162 5y ago
I would say keep an eye on dev dependencies which are a part of the build process. Malicious code there could easily append malicious code to the production build, even if you have a deployment server setup. This is just as dangerous as a malicious production dependency.

pyjug 5y ago

> In this architecture, the authorization service was properly validating user authorization to packages based on data passed in request URL paths. 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 I have a similar story . At my old job, we had a web socket gateway that authenticated using JWTs , then hit an internal service to request REST resources. The issue was that it didn’t actually validate the requested REST resource URL; a malicious user could authenticate as themselves but request a resource for any other account. I found it as I was getting up to speed on the code base, having recently switched teams. Funnily enough, nobody on the team really understood the vulnerability - the EM marked it low priority and wanted the team to work on other things. I had to essentially go directly to the security team and convince them it was a sev 1. I sometimes wonder if it’s easier to just report security issues as an outsider through the bug bounty program; internal reports don’t seem to get taken as seriously.

BarryMilo 5y ago

Am I the only to just say "fuck npm"? I've been saying it for a long time, but things like this confirm it. Don't get me wrong, everyone has security flaws and zero days, but I feel like npm has been mismanaged since its inception. I'm glad I'm out of the web dev game, I would dread having to rely on this walking security disaster.

mikestaub 5y ago
The leftpad fiasco stunned me. Such a gaping security flaw from the very beginning made me question everything.

dorianmariefr 5y ago

NPM should support Web Authentication API (e.g. security keys, touch ID, etc.) for 2-factor authentication.

gpmcadam 5y ago
how would 2fa work with automated build systems?
- dorianmariefr 5y ago
  the main use case is publishing packages. and automated systems could have API keys

lrvick 5y ago

Linux distros and Mobile Apps rarely see these issues for one simple reason: packages must all be signed by a vetted maintainer before they are ever submitted and every client has the ability to verify signatures came from approved maintainers who hold the signing keys. Phishing, bad 2FA, and vulnerabilities of the central repo upload path itself all go away with this simple tactic used by all sane package managers. Someone PRed this exact same effective strategy to NPM in 2013, and it was refused even as -optional-. https://github.com/npm/npm/pull/4016#issuecomment-76316744 https://github.com/npm/npm/pull/4016#issuecomment-76316744 NPM team members have ignorantly maintained that hashing packages is good enough. They insist on being a central authority for all packages with no method to strongly authenticate authors and this negligence has repeatedly endangered millions. Meanwhile Debian and other community Linux distros maintain, sign, and distribute hundreds of popular NodeJS packages themselves now because they realize it would be negligent to risk having NPM in their supply chain.

xvector 5y ago
I can't think of any other reason than incompetence for not requiring signed packages.