Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

socket.dev

Post reply on HN
Print view View original

851–860 of 1001 posts

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#851

Post by cesarb »

63stack wrote: post #836
electroly wrote: post #615

Earlier quoted context omitted.

That's only a problem for you, the developer, though, and is merely an annoyance about time spent. And it's all stuff you had to do anyway to update--you're just doing it all at once instead of spread out over time. A supply chain malware attack is a problem for every one of your users--who will all leave you once the dust is settled--and you end up in headline news at the top of HN's front page. These problems are n…

A log4j level vulnerability happens again. Do you need 10 minutes to update? 1 hour? 1 day? 1 week? Multiple months? The more you are drifting behind on updates, the worse it gets, which also affects every one of your users, your business, and might be the end of your project.

> A log4j level vulnerability happens again. [...] The more you are drifting behind on updates, the worse it gets

That one is a funny example in this context. If you were drifting far behind on updates, so far that you were still on the obsolete log4j 1.x, you were immune to that vulnerability (log4shell). That obsolete log4j version had other known vulnerabilities, but most of them on rarely used optional components, and none of them affected basic uses of it to log to the console or disk. And even better, there were so many people using that obsolete log4j version, that a binary compatible fork quickly appeared (reload4j) which just removes the vulnerable components (and fixes everything that wasn't removed); it takes 10 minutes to update to it, or at worst 1 hour if you have to tweak your dependencies to exclude the log4j artifact.

(And then it happened again, this time with Spring (spring4shell): if you were far behind on updates, so far that you were still on the very old but still somewhat supported Java 8, you were immune to that vulnerability.)

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#852

Post by darkwater »

2muchcoffeeman wrote: post #462
gameman144 wrote: post #416

Earlier quoted context omitted.

> It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies I think this is a good argument for reducing your dependency count as much as possible, and keeping them to well-known and trustworthy (security-wise) creators. "Not-invented-here" syndrome is counterproductive if you can trust all authors, but in an uncontrolled or unaudited ecosystem it's actually…

Have we all forgotten the left-pad incident? This is an eco system that has taken code reuse to the (unreasonable) extreme. When JS was becoming popular, I’m pretty sure every dev cocked an eyebrow at the dependency system and wondered how it’d be attacked.

Not on HN, the land of "you should use a SaaS or PaaS for that (because I might eventually work there and make money)" or "I don't want to maintain that code because it's not strictly related to my CRUD app business! how you dare!"

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#853

Post by user34283 »

znort_ wrote: post #166
kees99 wrote: post #109

Earlier quoted context omitted.

I agree other repos deserve a good look for potential mitigations as well (PyPI too, has a history of publishing malicious packages). But don't brush off "special status" of NPM here. It is unique in that JS being language of both front-end and back-end, it is much easier for the crooks to sneak in malware that will end up running in visitor's browser and affect them directly. And that makes it a uniquely more attrac…

npm in itself isn't special at all, maybe the userbase is but that's irrelevant because the mitigation is pretty easy and 99.9999% effective, works for every package manager and boils down to: 1- thoroughly and fully analyze any dependency tree you plan to include 2- immediately freeze all its versions 3- never update without very good reason or without repeating 1 and 2 in other words: simply be professional, face l…

Do tell: how many packages are in your dependency graph?

I bet it's hundreds.

Jest alone adds 300 packages.

Consequently I doubt that you in fact "thoroughly and fully" analyzed all your dependencies.

Unless what you're shipping isn't a feature rich app, what you proposed seems entirely unrealistic.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#854

Post by p0w3n3d »

wvh wrote: post #823
kelnos wrote: post #405

As 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…

As a security guy, for years, you get laughed out of the room suggesting devs limit their dependencies and don't download half of the internet while building. You are an obstruction for making profit. And obviously reading the code does very little since modern (and especially Javascript) code just glues together frameworks and libraries, and there's no way a single human being is going to read a couple million lines…

> You are an obstruction for making profit.

This explains a lot. Really, this is the great reason of why the society is collapsing as we speak.

"There should be no DRM in phones" - "You Are An Obstruction To Making Profit".

"People should own their devices, we must not disallow custom software on it" - "YAAOTMP"

"sir, the application will weigh 2G and do almost nothing yet, should we minify it or use different framework?" - "YAAOTMP".

"Madame, this product will cost too much and require unnecessary payments" - "YAAOTMP"

Etc. etc. Like in this "Silicon Valley" comedy series. But for real, and affecting us greatly.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#855

Post by user34283 »

WorldMaker wrote: post #297
skydhash wrote: post #204

Earlier quoted context omitted.

Stuff like Babel, React, Svelte, Axios, Redux, Jest… should be self contained and not depend on anything other than being a peer dependency. They are core technological choices that happens early in the project and is hard or impossible to replace afterwards.

- I feel that you are unlikely to need Babel in 2025, most things it historically transpiled are Baseline Widely Available now (and most of the things it polyfilled weren't actually Babel's but brought in from other dependencies like core-js, which you probably don't need either in 2025). For the rest of the things it still transpiles (pretty much just JSX) there are cheaper/faster transpilers with fewer external dep…

Jest alone adds 300 packages by the way.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#856

Post by jen729w »

wvh wrote: post #823
kelnos wrote: post #405

As 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…

As a security guy, for years, you get laughed out of the room suggesting devs limit their dependencies and don't download half of the internet while building. You are an obstruction for making profit. And obviously reading the code does very little since modern (and especially Javascript) code just glues together frameworks and libraries, and there's no way a single human being is going to read a couple million lines…

At my previous enterprise we had a saying:

Security: we put the ‘no’ in ‘innovation’.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#857

Post by homebrewer »

whilenot-dev wrote: post #830
internet_points wrote: post #813

Earlier quoted context omitted.

The above script wraps npm. PWD gets evaluated before npm is called (so PWD is expanded in the "outside" environment). Of course, if your malicious actor has access to your environment already, they can redefine PWD, but that's assuming you're already compromised. This bwrap script is to avoid that malicious actor running malicious install scripts in the first place. However, I don't think it protects you against stu…

I was more thinking if the malicious script calls npm itself, recursively... it could even redefine $PATH again to skip the next call to the bubblewrap wrapper scriptlet. I don't know if bwrap protects from that.

You can't really escape it AFAIK, except by using kernel vulnerabilities. Once you're in the sandbox, you can only call and read/write whatever was available when you entered it.

If you have a Linux system nearby, set it up and run `pnpm bash`, and then walk around the system and look at what you can see and do. (Not much.)

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#858

Post by user34283 »

tarruda wrote: post #57
codemonkey-zeta wrote: post #31

I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. Vendoring can mitigate your immediate exposure, but does not solve this problem. These attacks may just be the final push I needed to take server rendering (without js) more seriously. The HTMX folks convinced me that I can get REALLY far without any JavaScript, and my apps will probab…

AFAICT, the only thing this attack relies on, is the lack of scrutiny by developers when adding new dependencies. Unless this lack of scrutiny is exclusive to JavaScript ecosystem, then this attack could just as well have happened in Rust or Golang.

There is little point in you scrutinizing new dependencies.

Many who claim to fully analyze all dependencies are probably lying. I did not see anyone in the comments sharing their actual dependency count.

Even if you depend only on Jest - Meta's popular test runner - you add 300 packages.

Unless your setup is truly minimalistic, you probably have hundreds of dependencies already, which makes obsessing over some more rather pointless.

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#859

Post by spoiler »

burntsushi wrote: post #607
spoiler wrote: post #288

Earlier quoted context omitted.

Not saying this in defence of Rust or Cargo, but often times those dependencies are just different versions of the same thing. In a project at one of my previous companies, a colleague noticed we had LOADS of `regex` crate versions. Forgot the number but it was well over 100

That doesn't make sense. The most it could be is 3: regex 0.1.x, regex 0.2.y and regex 1.a.b. You can't have more because Cargo unifies on semver compatible versions and regex only has 3 semver incompatible releases. Plus, regex 1.0 has been out for eons. Pretty much everyone has moved off of 0.1 and 0.2.

The reason he went down this rabbit hole was because he was chronically running low on disk space, and his target dir was one of the largest contributors.

Not sure how he actually got the number; this was just a frustrated Slack message like 4 years ago

A sibling comment mentions we could have been using Cargo workspaces wrong... So, maybe?

Re: Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

#860

Post by user34283 »

benmccann wrote: post #156
homebrewer wrote: post #66

When 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…

Yes, eslint is particularly frustrating: https://npmgraph.js.org/?q=eslint There are plenty of people in the community who would help reduce the number of dependencies, but it really requires the maintainers to make it a priority. Otherwise the only way to address it is to switch to another solution like oxlint.

That's like 85 dependencies, not hundreds or even thousands.

Jest pulls in 300 by the way.

Post reply on HN