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

611–620 of 1001 posts

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

#611

Post by brw »

theodorejb wrote: post #341
debazel wrote: post #326

Earlier quoted context omitted.

Even if we didn't have post install scripts wouldn't the malware just run as soon as you imported the module into your code during the build process, server startup, testing, etc? I can't think of an instance where I ran npm install and didn't run some process shortly after that imported the packages.

Many people have non-JS backends and only use npm for frontend dependencies. If a postinstall script runs in a dev or build environment it could get access to a lot of things that wouldn't be available when the package is imported in a browser or other production environment.

I wonder why npm doesn't block pre/postinstall scripts by default, which pnpm and Bun (and I imagine others) already do.

EDIT: oh I scrolled down a bit further and see you said the exact same thing in a top-level comment hahah, my bad

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

#612

Post by LtWorf »

gmueckl wrote: post #517
hermannj314 wrote: post #474

Earlier quoted context omitted.

Almost all software has a no warranty clause. I am not a lawyer but in pretty plain English every piece of software I have ever used has said exactly that I can fuck off if I expect it to work or do anything. To clarify - I dont think it is naive to assume the software is as-is with all responsibilities on the user since that is exactly what lawyers have made all software companies say that for over 50 years.

Product liability is coming for software. Warranty disclaimers in licenses will be rendered ineffective by the end of 2026 at the latest.

only if you pay for it… otherwise you are liable but don't have anyone else to blame.

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

#613

Post by LtWorf »

tcoff91 wrote: post #586
gmueckl wrote: post #517

Earlier quoted context omitted.

Product liability is coming for software. Warranty disclaimers in licenses will be rendered ineffective by the end of 2026 at the latest.

Source? An open source library is not necessarily a ‘product’ at all.

No source because it's not real. There's talk about final products and making the companies selling them responsible. But open source developers are not responsible.

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

#614

Post by IgorPartola »

sgc wrote: post #437
Pet_Ant wrote: post #412

Earlier quoted context omitted.

I find that the issue is much more often not updating dependencies often enough with known security holes, than updating too often and getting hit with a supply-chain malware attack.

There have been several recent supply chain attacks that show attackers are taking advantage of this (previously sensible) mentality. So it is time to pivot and come up with better solutions before it spirals out of control.

A model that Linux distros follow would work to an extent: you have developed of packages and separate maintainers who test and decide to include or exclude packages and versions of packages. Imagine a JS distro which includes the top 2000 most popular libraries that are all known to work with each other. Your project can pull in any of these and every package is cryptographically signed off on by both the developers and the maintainer.

Vulnerabilities in Linux distro packages obviously happen. But a single developer cannot push code directly into for example Debian and compromise the world.

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

#615

Post by electroly »

63stack wrote: post #539
duped wrote: post #489

Earlier quoted context omitted.

Personally, I go further than this and just never update dependencies unless the dependency has a bug that affects my usage of it. Vulnerabilities are included. It is insane to me how many developers update dependencies in a project regularly. You should almost never be updating dependencies, when you do it should be because it fixes a bug (including a security issue) that you have in your project, or a new feature t…

Then you run the risk of drifting so much behind that when you actually have to upgrade it becomes a gargantuan task. Both ends of the scale have problems.

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 not comparable. One is a rough day. The other is the end of your project.

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

#616

Post by j1elo »

gameman144 wrote: post #441
EGreg wrote: post #427

Earlier quoted context omitted.

Exactly. I always tried to keep the dependencies to a minimum. Another thing you can do is lock versions to a year ago (this is what linux distros do) and wait for multiple audits of something, or lack of reports in the wild, before updating.

I saw one of those word-substition browser plugins a few years back that swapped "dependency" for "liability", and it was basically never wrong. (Big fan of version pinning in basically every context, too)

I'm re-reading all these previous comments, replacing "dependency" for "liability" in my mind, and it's being quite fun to see how well everything still keeps meaning the same, but better

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

#617

Post by collinmanderson »

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…

> sort of a "delayed" mode to updating my own dependencies. The idea is that when I want to update my dependencies, instead of updating to the absolute latest version available of everything, it updates to versions that were released no more than some configurable amount of time ago.

For Python's uv, you can do something like:

> uv lock --exclude-newer $(date --iso -d "2 days ago")

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

#618

Post by [deleted] »

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…

[deleted]

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

#619

Post by ojosilva »

spion wrote: post #486
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…

pnpm just added minimum age for dependencies https://pnpm.io/blog/releases/10.16#new-setting-for-delayed-...

From your link:

> In most cases, such attacks are discovered quickly and the malicious versions are removed from the registry within an hour.

By delaying the infected package availability (by "aging" dependencies), we're only delaying the time, and reducing samples, until it's detected. Infections that lay dormant are even more dangerous than explosives ones.

The only benefit would be if, during this freeze, repository maintainers were successfully pruning malware before it hits the fan, and the freeze would give scanners more time to finish their verification pipelines. That's not happening afaik, NPM is crazy fast going from `npm publish` to worldwide availability, scanning is insufficient by many standards.

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

#620

Post by dismalaf »

kelnos wrote: post #553
TZubiri wrote: post #509

Earlier quoted context omitted.

Install less dependencies, code more.

Sure, and I do that whenever I can. But I'm not going to write my own react, or even my own react-hook-form. I'm not going to rewrite stripe-js. Looking through my 16 direct dependencies -- that pull in a total of 653 packages, jesus christ -- there's only one of them that I'd consider writing myself (js-cookie) in order to reduce my dependency count. The rest would be a maintenance burden that I shouldn't have to ta…

React has zero dependencies and Stripe has one... What else do you need?
Post reply on HN