ctrl/tinycolor and 40+ NPM Packages Compromised
25 points by repl
25 points by repl
Is it just me, or was this article clearly written by a GPT? There’s a lot of weird details for no reason, like the repeated references to process.env (as if there’s something novel about this use of process.env - just say “it checks the environment”?), or the description of the malware “using [AWS] SDK pagination” to scan Secrets Manager. Like, this is just a bizarre detail to include - and what does it mean by “execution is likely triggered via a hijacked postinstall script”? Either it’s triggered that way, or it isn’t.
Just frustrating to read, honestly. I gave up pretty quickly since it was obvious the writing was low-quality.
Yeah, it reads this way to me too. But the problem is real, as far as I can tell.
@pushcx: the person who originally published this seems to have login-walled their linkedin posts where they shared it. This:
https://socket.dev/blog/tinycolor-supply-chain-attack-affects-40-packages
might be a good link to add to this post for more reliable reporting.
The compromise begins with a sophisticated minified JavaScript bundle injected into affected packages
Tbh that sounds like the middle of the compromise. How was the minified bundle injected into the packages in the first place? Was it another successful phishing attack?
It’s funny (and a little shocking) that something can be true enough that it becomes a meme - doing anything with NPM means installing hundreds, sometimes thousands of dependencies most which aren’t really needed - yet nobody takes it seriously enough to do something.
I wonder if this and the “Software packages with more than 2 billion weekly downloads hit in supply-chain attack” problem are enough to nudge people in the direction of fewer dependencies == good, or if this is now the new normal.
These are unfortunate side effects of “curl | sudo bash” culture that trust any random package downloaded from the internet. npm repo as it exists today is a minefield, and a rich target for adversaries to compromise supply chains.
That’s sort of unfair. apt-get install has the same threat model. You aren’t just trusting the specific program/library whose name you typed, but all its transitive dependencies as well. This exacerbated in an environment like NPM where dependencies can be very lightweight and individual packages can have a lot of them.
While the threat models are similar (both offer packages that can be installed on an OS and as a result face similar threats more or less), they way they go about addressing the threats makes Debian more trustworthy than npm registry.
apt-get install, unless you’ve explicitly trusted additional keys, will only install packages that have been signed by members of a community that have established real-world trust relationships. That’s very different from NPM (or cargo, pypi, etc)