Does anyone know when @ctrl/tinycolor 4.1.1 was released exactly? Trying to figure out the infection timeline relative to my tools.
Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
501–510 of 1001 posts
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#502Earlier quoted context omitted.
I can tell a lot about a dev by the fact that they single out npm/js for this supply chain issue.
What other language ecosystems have had this happen systematically? This isn't even the first time this month!
NPM is the most popular, so it happens the most frequently. All of the other ecosystems are just as susceptible.
Unix had a big scare last year because of XZ Utils.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#503Earlier quoted context omitted.
They are. Any language that depends heavily on package managers and lacks a standard lib is vulnerable to this. At some point people need to realize and go back to writing vanilla js, which will be very hard. The rust ecosystem is also the same. Too much dependence on packages. An example of doing it right is golang.
The solution is not to go back to vanilla JS, it's for people to form a foundation and build a more complete utilities library for JS that doesn't have 1000 different dependencies, and can be trusted. Something like Boost for C++, or Apache Commons for Java.
> Something like Boost for C++, or Apache Commons for Java.
Honestly I wish Python worked this way too. The reason people use Requests so much is because urllib is so painful. Changes to a first-party standard library have to be very conservative, which ends up leaving stuff in place that nobody wants to use any more because they have higher standards now. It'd be better to keep the standard library to a minimum needed more or less just to make the REPL work, and have all of that be "builtin" the way that `sys` is; then have the rest available from the developers (including a default "full-fat" distribution), but in a few separately-obtainable pieces and independently versioned from the interpreter.
And possibly maintained by a third party like Boost, yeah. I don't know how important that is or isn't.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#504This 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…
This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them, thereby giving hundreds of third-parties access to their build (or worse) execution environments. Adding friction to the sharing of code doesn't absolve developers from their decision to blindly trust a ridiculous amount of third-…
See auto update bots on Github. https://docs.github.com/en/code-security/dependabot/dependab... And since Github does it, it must be a good thing, right? Right???
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#505This 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…
This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them, thereby giving hundreds of third-parties access to their build (or worse) execution environments. Adding friction to the sharing of code doesn't absolve developers from their decision to blindly trust a ridiculous amount of third-…
> This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them
I do not know about NPM. But in Rust this is common practice.
Very hard to avoid. The core of Rust is very thin, to get anything done typically involves dozens of crates, all pulled in at compile time from any old developer implicitly trusted.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#506I think these kinds of attack would be strongly reduced if js had a strong standard library. If it was provided, it would significantly trim dependency trees of all the small utility libraries. Perhaps we need a common community effort to create a “distro” of curated and safe dependencies one can install safely, by analyzing the most popular packages and checking what’s common and small enough to be worth being inclu…
Ever seen XKCD #927? (https://xkcd.com/927)
Joking aside, I don't think there ever really was a lack of initiatives by entities (communities, companies, whatever) to create some sort of standard library (we typically tend to call them frameworks). There's just simply too much diversity, cultures and subcultures within the whole JavaScript sphere to ever get a global consensus on what that "standard" library then should look like. Not to mention the commercial entities with very real stakes in things they might not want to relinquish to some global unity consensus (as it may practically hurt their current bottom line).
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#507Earlier quoted context omitted.
It's too bad MS doesn't own npm, and/or GitHub repositories. Wait
Nuget, Powershell gallery, the marketplaces for VSCode/VS/AZDo and the Microsoft Store too. Probably another twenty. They collect package managers like funko pops. I'm not quite sure about the goal. Maybe some more C# dev kit style rug-pulls where the ecosystem is nominally open-source but MS own the development and distribution so nobody would bother to compete.
I took those acquisitions and a few others like LinkedIn and all the visual studio versions as a sign that Microsoft is trying to own the software engineer career as a domain.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#508Earlier quoted context omitted.
Not updating is the other side of the same problem: library owners feel it is ok to make frequent backwards-compatibility breaking changes, often ignoring semver conventions. So consumers of their libraries are left with the choice to pin old insecure versions or spend time rewriting their code (and often transitive dependency code too) to keep up. This is what happens when nobody pays for anything and nobody feels t…
>This is what happens when nobody pays for anything and nobody feels they have a duty to do good work for free. Weirdly, some of the worst CVE I can think of were with enterprize software.
That's because there many people don't feel like it is their duty to do good work, even though they are paid ...
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#509As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…
Install less dependencies, code more.
Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised
#510As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embed…
If you pull something into your project, you're responsible for it working. Full stop. There are a lot of ways to manage/control dependencies. Pick something that works best for you, but be aware, due diligence, like maintenance is ultimately your responsibility.
Acknowledging your responsibility doesn't make the problem go away. It's still better to have extra layers of protection.
I acknowledge that it is my responsibility to drive safely, and I take that responsibility seriously. But I still wear a seat belt and carry auto insurance.