GitHub repo (800+ stars) on a list of tips for protecting against npm supply chain attacks: https://github.com/bodadotsh/npm-security-best-practices
There's no magical solution, you just have to use (WAY) less dependencies
Malicious npm packages detected across Red Hat Cloud Services
431–440 of 494 posts
Re: Malicious npm packages detected across Red Hat Cloud Services
#432About a week ago, I uninstalled Node from my laptop, which felt great. :) I'm trying to do all work in dev containers (or other sandboxes), limiting the blast radius if I'm unlucky enough to be hit by an exploit. The attackers may get a Claude token, but they won't easily be able to escape the container and scan my home dir. Cooldowns and allow-listing of installer scripts are good additions to layered security, espe…
Are you using something like Bubblewrap/Firejail/Flatpak, or what does such a setup look like? I've been entertaining a similar idea for a while but haven't gotten to it
I'm using VSCode dev containers, powered by Podman on a Mac.
Most people would probably choose Docker over Podman but I'm weary of Docker and wanted to try something else. I would not consider myself an expert on containers but with the help of Claude I've been able to fight my way through various challenges:
* Persist a volume for Claude so that conversations don't get blown away with every container rebuild. An attacker may still be able to get a Claude token from me, which is something I'd like to tighten up in the future.
* Fix file permissions issues by running rootful inside the container. (The container process still runs on the host as an ordinary user. Since my threat model is "compromised dependency scanning for credentials in project dir and home dir" rather than "attacker escaping the container", I figured that was good enough to get started.)
* Work around architectural availability issues with precompiled PyPI libraries. This I punted on by choosing a different approach and eliminating the problematic dependency (by writing my hobbyist CAD 3d printing stuff using Blender extensions instead of CadQuery). I've gotten the impression that dependency compatibility with a container workflow is an ongoing challenge.
* Run a database in a docker-compose sidecar for integration testing.
For all the projects I'm containerizing I'm the solo dev with full control over the Git repo so I can make the call to add a `.devcontainer/devcontainer.json` config file. I haven't yet explored how to isolate projects I don't control.
Re: Malicious npm packages detected across Red Hat Cloud Services
#433NPM broken by design. And the NIH syndrom that runs rampant in the community wont let them do anything simple.
One common fallacy of the NIH folk is that reinventing X package would take a lot of time.
But first, you will of course not remake every single feature, just the one you need.
And furthermore, when you code just one feature, you don't need to make any abstraction or additional function interfaces. So it's cheaper, and probably better integrated.
Another fallacy is that you'll make bugs and introduce vulnerabilities. Maybe, if you are a bad programmer, but you will also avoid a category of bugs where the vuln is introduced at the boundary of the integration between two different libraries that weren't designed to fit exactly together. (Many such cases)
Re: Malicious npm packages detected across Red Hat Cloud Services
#434Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days). https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
The package event-stream was compromised and went unnoticed for 60 days: https://medium.com/intrinsic-blog/compromised-npm-package-ev... The package axios was compromised, and hijacked the author's credentials, so every attempt at a fix was unfixed. https://www.trendmicro.com/en_us/research/26/c/axios-npm-pac... The xz utility was backdoored for 2 months: https://gigazine.net/gsc_news/en/20240403-timeline-of-xz-ope..…
[dead]
Re: Malicious npm packages detected across Red Hat Cloud Services
#435Earlier quoted context omitted.
IMHO those are both lipstick on a pig solutions. Ultimately all this stuff is just a variation of "make releases harder to publish", which isn't going to do anything but train people to evade them. Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise. The bug here isn't that we need to better authenticate…
But there is a second level of people reviewing packages on npm. They're the ones that report issues like the github issue this HN thread is linked to, and they very frequently get malicious npm packages taken down within a day of publishing. The big issue is just that not everyone is using a cooldown to avoid packages less than a day old and so people who install new packages at unlucky times don't get the benefit o…
> they very frequently get malicious npm packages taken down within a day of publishing
If I'm reading the secondarily-linked blog post correctly, this was live for 12 days before discovery.
Re: Malicious npm packages detected across Red Hat Cloud Services
#436Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised): I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cool…
> Hope it's ok I hijack this thread again about setting up cooldowns...
In addition to cooldowns it'd be nice if more package managers did triage between security fixes and normal releases (bug fix / performance improvement / new functionalities).
It's totally possible to say: "A security fix must only be a security fix and cannot ship any other feature".
Then, for a start, a security fix becomes easier to audit (both by security researchers and by the tools security researchers are using).
And then a cooldown can be used for the regular releases (e.g. non security-related bug fixes, perfs improvements, new functionalities, etc.) but no cooldown (or a much smaller countdown) for security fixes.
Something has to be said about a system like Debian where you can have an extremely stable server and you can configure unattended upgrades to only apply security fixes but nothing else.
Such new package releases are easier to audit by security researchers.
Re: Malicious npm packages detected across Red Hat Cloud Services
#437Earlier quoted context omitted.
> Changing your own car's oil is actually not that hard It is. Changing oil requires a place where you have sufficient access to the vehicle to drain it; the right equipment; the right disposal solutions. Most people who have cars do not have that. And it takes significantly more time to change your own oil than to have someone else do it as part of other specialist maintenance. > Think of QR codes, people hardly use…
Changing oil requires > a place where you have sufficient access to the vehicle to drain it Probably the only valid argument for people who park on the street. > the right equipment One $5 wrench, one $10 filter wrench (optional). One set of ramps ($40), or jack stands ($30) if you already have a jack. One drain pan, $10 (or free if you're resourceful). Total cost max $65. Cheaper if you look for deals, buy used, bor…
My favorite way to do it is in the auto parts store parking lot. They will help you cart your full drain pan back to their oil recycling receptacle and some will even prop the back door open for you to walk it straight there. The bonus being if you do happen to spill a bit you're not stuck having to power wash your own driveway. I've got a process down to where I can pull it off with one pair of nitrile gloves, one rag, and one trash bag, to keep any residue from the drain pan staining anything.
Re: Malicious npm packages detected across Red Hat Cloud Services
#438In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair. There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and others) have implemented in response to protect package consumers. That bit that's getting less conversation is the tools on the package maintai…
IMHO those are both lipstick on a pig solutions. Ultimately all this stuff is just a variation of "make releases harder to publish", which isn't going to do anything but train people to evade them. Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise. The bug here isn't that we need to better authenticate…
> Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise.
Mandating that the final binary is compiled without having any access to any test file though would have prevented the xz-utils backdoor as it was conceived though.
A proper packaging setup would first verify that all the tests are passing and happen in an isolated environment. And that isolated environment either returns which tests failed or gives the green light.
When the greenlight is given (that all tests are passing), another environment should first delete all files related to tests and then build (in a bit-for-bit reproducible way btw and we're basically here already so that's good) the final binary / package.
If you prepare your final package in an environment that has access to test files, there are simply way too many ways obfuscated binary data can be hidden in test cases / test files.
I'm not saying the NSA (sorry, Jia Tan) wouldn't have tried something else but I think we should really move to build/packaging that discards non essential data/files before compiling.
P.S: note that as a side-effect of reproducible builds... If we have reproducible builds and if we add, later on, a builder/packager that discards tests files and ends up with a final package that's not bit-for-bit identical to the package created while having access to the test files during the build, we've just detected a backdoor hidden inside test files (like the XZ utils one). As a really mindboggling food for thoughts: if we were to recompile all the Debian binary packages that are already reproducible today (95% of them), but while discarding all tests files before the build, we may catch other backdoors.
Re: Malicious npm packages detected across Red Hat Cloud Services
#439Earlier quoted context omitted.
I wish that was the case. Asking people to do something simple, doesn't matter how simple it is, depends on how simple they view it. Changing your own car's oil is actually not that hard, once you know how to do it, most people don't even try. Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the ca…
In what way is "edit your .npmrc" simple?!? The JS ecosystem is really, really complicated, so any non-trivial app is going to use multiple bundlers, node runtimes, native runtimes, etc, etc, etc. Every one of those has a different opinion about how to spell "cooldown". On top of that, there's the bootstrapping issue of "I want to install the N pieces of ecosystem sprawl that read the .[p]npmrc that have the cooldown…
> The JS ecosystem is really, really complicated, so any non-trivial app is going to use multiple bundlers, node runtimes, native runtimes, etc, etc, etc.
This statement makes very little sense to me. I've worked on several of what are likely the largest JS monorepos in the world, and they all define a specific version of a specific runtime and package manager you should be using.
Re: Malicious npm packages detected across Red Hat Cloud Services
#440[dead]