I had just seen some guy on TikTok pushing `mcp-knowledge-graph` the other day
Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
491–500 of 1001 posts
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#492When the left-pad debacle happened, one commenter here said of a well known npm maintainer something to the effect of that he's an "author of 600 npm packages, and 1200 lines of JavaScript". Not much has changed since then. The best counter-example I know is esbuild, which is a fully featured bundler/minifier/etc that has zero external dependencies except for the Go stdlib + one package maintained by the Go project i…
The downside is now I need to know Golang to audit my JavaScript project.
And it runs a post-install: node install.js
So I do really have to trust it or read all the code.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#493When the left-pad debacle happened, one commenter here said of a well known npm maintainer something to the effect of that he's an "author of 600 npm packages, and 1200 lines of JavaScript". Not much has changed since then. The best counter-example I know is esbuild, which is a fully featured bundler/minifier/etc that has zero external dependencies except for the Go stdlib + one package maintained by the Go project i…
> Very encouraging, until you find the Rust source
Those are the workspace dependencies, not the dependencies of the specific crates you may use within the project. You have to actually look closer to find that out, most of `swc-` crates have shallow dependency trees.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#494This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…
The lack of an easy method to automatically pull in and manage dependencies in C/C++ is starting to look a lot more like a feature than a bug now.
But there's so much UB in C++ that can be exploited that I doubt attackers lament the lack of a module system to target. ;)
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#495This happens because there's no auditing of new packages or versions. The distro's maintainer and the developer is the same person. The general solution is to do what Debian does. Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Keep a testing/unstable distro where new packages and new versions can…
> Keep a stable distro where new packages aren't added and versions change rarely (security updates and bugfixes only, no new functionality). This is what most people use. Unfortunately most people don't want old software that doesn't support newer hardware so most people don't end up using Debian stable.
Enable the Backport sources. The recent kernels there have supported all my modern personal devices.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#496Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#497So, other packaging environments have a tendency to slow down the rate of change that enters the user's system. Partly through the labor of re-packaging other people's software, but also as a deliberate effort. For instance: Ubuntu or RedHat. Is anyone doing this in a "security as a service" fashion for JavaScript packages? I imagine a kind of package escrow/repository that only serves known secure packages, and acti…
I've worked in companies that do this internally, e.g., managed pull-through caches implemented via tools like Artifactory, or home-grown "trusted supply chain" automation, i.e., policy enforcement during CI/CD prior to actually consuming a third-party dependency.
But what you describe is an interesting idea I hadn't encountered before! I assume such a thing would have lower adoption within a relatively fast-moving ecosystem like Node.js though.
The closest thing I can think of (and this isn't strictly what you described) is reliance on dependabot, snyk, CodeQL, etc which if anything probably contributes to change management fatigue that erodes careful review.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#498Earlier quoted context omitted.
I’m using windows again. By default windows has “power shell” which is not at all like bash and is (how do I say this diplomatically)… wanting. I mean it says something the developed the Linux Subsystem for Windows, but it’s an optional install.
What dont you like about powershell? I'm a die hard linux user, and some years ago took a windows gig on a whim. I find powershell fantastic and the only thing that makes my role bearable. Now, one of the first things i install on Linux is powershell.
The awk equivalents in power-shell are horrific.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#499Earlier quoted context omitted.
> in JS land almost everyone uses lax dependency declarations They do, BUT. Dependency versioning schemes are much more strictly adhered to within JS land than in other ecosystems. PyPi is a mishmash of PEP 440, SemVer, some packages incorrectly using one in the format of the other, & none of the 3 necessarily adhering to the standard they've chosen. Other ecosystems are even worse. Also - some ecosystems (PyPi again…
The point is still different. In PyPI, if I put `requests` in my requirements.txt, and I run `pip install -r requirements.txt` every time I do `make build`, I will still only get one version of requests - the latest available the first time I installed it. This severely reduces the attack radius compared to NPM's default, where I would get the latest (patch) version of my dependency every day. And the ecosystem being…
Generally you have the right of it, but a word of caution for Pythonistas:
> The point is still different. In PyPI, if I put `requests` in my requirements.txt, and I run `pip install -r requirements.txt` every time I do `make build`, I will still only get one version of requests - the latest available the first time I installed it.
Only because your `make build` is a custom process that doesn't use build isolation and relies on manually invoking pip in an existing environment.
Ecosystem standard build tools (including pip itself, using `pip wheel` — which really isn't meant for distribution, but some people seem to use it anyway) default to setting up a new virtual environment to build your code (and also for each transitive dependency that requires building — to make sure that your dependencies' build tools aren't mutually incompatible, or broken by other things in the envrionment). They will read `requests` from `[project.dependencies]` in your pyproject.toml file and dump the latest version in that new environment, unless you use tool-specific configuration (or of course a better specification in pyproject.toml) to prevent that. And if your dependencies were only available as sdists, the build tool would even automatically, recursively attempt to build those, potentially running arbitrary code from the package in the process.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#500Earlier quoted context omitted.
The malware is modifying files and adding github workflows. If your builds are reproducible and run from committed code then the only way to add the post install script is if the maintainer reviews and accepts the commit that adds it. Similarly with the github workflow branch. And if your CI is building and releasing in a sandboxed hermetic environment, then the sandboxes that build and release don't need credentials…
> The malware is modifying files and adding github workflows. If your builds are reproducible and run from committed code Exactly: it can simply commit its code and trigger a CI-only GitHub Actions deploy with no input from the maintainer at all.
Not from a the malicious branch.
By hypothesis the code only deploys from code committed to the main branch (or whatever the blessed branch for CI is). To create a GitHub Action that can deploy the code, the package maintainer must first manually approve and merge the malicious commit.
And the malware spreads by publishing new versions of NPM packages using credentials on the package owner's development machine. If the package owner didn't have credentials with publish access, this wouldn't spread like a worm. And if they had reproducible builds they wouldn't pull a new version of their dependencies from NPM at build time because they'd have to have pinned specific versions with specific hashes to get reproducibility.
Under these hypotheses it can spread, but only if the package owner manually pins a malicious version or manually approves a malicious commit.