Why did the socket.dev story from last night get flagged off the front page?
Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
21–30 of 1001 posts
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#22Is there a theoretical framework that can prevent this from happening? Proof-carrying code?
Manual verification of releases and chain-of-trust systems help a lot. See for example https://lucumr.pocoo.org/2019/7/29/dependency-scaling/
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#23I knew npm was a train wreck when I first used it years ago and it pulled in literally hundreds of dependencies for a simple app. I avoid anything that uses it like the plague.
So basically you live JavaScript free?
I mean, it's hard to avoid indirectly using things that use npm, e.g. websites or whatever. But it's pretty easy to never have to run npm on your local machine, yes.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#24My main takeaway from all of these is to stop using tokens, and rely on mechanisms like OIDC to reduce the blast radius of a compromise. How many tokens do you have lying around in your home directory in plain text, able to be read by anything on your computer running as your user?
> How many tokens do you have lying around in your home directory in plain text, able to be read by anything on your computer running as your user?
Zero? How many developers have plain-text tokens lying around on disk? Avoiding that been hammered into me from every developer more senior than me since I got involved with professional software development.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#25Warning: LLM-generated article, terribly difficult to follow and full of irrelevant details.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#26Is there a theoretical framework that can prevent this from happening? Proof-carrying code?
Probably signatures could alleviate most of these issues, as each publish would require the author to actually sign the artifact, and setup properly with hardware keys, this sort of malware couldn't spread. The NPM CI tokens that don't require 2fa kind of makes it less useful though. Clojars (run by volunteers AFAIK) been doing signatures since forever, not sure why it's so difficult for Microsoft to follow their own…
I would like to see more usage of NPM/Github Actions provenance statements https://www.npmjs.com/package/sigstore#provenance through the ecosystem
> The NPM CI tokens that don't require 2fa kind of makes it less useful though
Use OIDC to publish packages instead of having tokens around that can be stolen or leaked https://docs.npmjs.com/trusted-publishers
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#27My main takeaway from all of these is to stop using tokens, and rely on mechanisms like OIDC to reduce the blast radius of a compromise. How many tokens do you have lying around in your home directory in plain text, able to be read by anything on your computer running as your user?
> How many tokens do you have lying around in your home directory in plain text, able to be read by anything on your computer running as your user? Zero? How many developers have plain-text tokens lying around on disk? Avoiding that been hammered into me from every developer more senior than me since I got involved with professional software development.
How do you manage secrets for your projects?
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#28Is there a theoretical framework that can prevent this from happening? Proof-carrying code?
There are, but they have huge performance or usability penalties. Stuff like intents "this is a math library, it is not allowed to access the network or filesystem". At a higher level, you have app sandboxing, like on phones or Apple/Windows store. Sandboxed desktop apps are quite hated by developers - my app should be allowed to do whatever the fuck it wants.
Do they actually have huge performance penalties in Javascript?
I would have thought it wouldn't be too hard to design a capability system in JS. I bet someone has done it already.
Of course, it's not going to be compatible with any existing JS libraries. That's the problem.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#29Is there a theoretical framework that can prevent this from happening? Proof-carrying code?
Object-capability model / capability-based security.
Do not let code to have access to things it's not supposed to access.
It's actually that simple. If you implemented a function which formats a string, it should not have access to `readFile`, for example.
Retrofitting it into JS isn't possible, though, as language is way too dynamic - self-modifying code, reflection, etc, means there's no isolation between modules.
In a language which is less dynamic it might be as easy as making a white-list for imports.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#30We've seen many reports of supply chain attacks affecting NPM. Are these symptoms of operational complexity, which can affect any such service, or is there something fundamentally wrong with NPM?
It's actually relatively simple.
Adding dependencies comes with advantages and downsides. You need to strike a balance between them. External libraries can help implement things that you better don't implement yourself, so the answer is certainly not "no dependencies". But there are downsides and risks, and the risks grow with the number of dependencies.
In the world of NPM, people think those simple truths don't apply to them and the downsides and risks of dependencies can be ignored. Then you end up with thousands of transitive dependencies.
They're wrong and learn it the hard way now.