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

441–450 of 1001 posts

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

#441

Post by gameman144 »

EGreg wrote: post #427
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…

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)

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

#442

Post by cyberax »

kelnos wrote: post #421
Maskawanian wrote: post #348

Earlier quoted context omitted.

Golang at least gives you the option to easily vendor-ize packages to your local repository. Given what has happened here, maybe we should start doing this more!

This doesn't really help you. I assume Go records the sha1 hash of the commit it grabs, so it doesn't really matter if you vendor it, or download it every time. The problem comes when you want to upgrade your dependencies. How do you know that they are trustworthy on first use?

Go uses the hash of the source code, not the commit ID. So there's no difference between vendoring and using the central repo.

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

#443

Post by jauntywundrkind »

CraftThatBlock wrote: post #413
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 this: https://pnpm.io/blog/releases/10.16

minimumReleaseAge is pretty good! Nice!!

I do wish there were some lists of compromised versions, that package managers could disallow from.

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

#444

Post by maxverse »

201984 wrote: post #393
rectang wrote: post #306

Earlier quoted context omitted.

Acronym expansion for those-not-in-the-know (such as me before a web search): WAI might mean "working as intented", or possibly "why?"

Thank you. It's frustrating when people uncommon acronyms without explaining them.

AI is helpful for this, but I also built https://www.hackterms.com eight years ago for this exact reason.

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

#445

Post by dboreham »

Pet_Ant wrote: post #412
ncruces wrote: post #381

Earlier quoted context omitted.

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

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.

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 they have a duty to do good work for free.

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

#446

Post by cycomanic »

Meneth wrote: post #91

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

I've been arguing a couple of times that the 2 main reasons people want package management in languages are

1. Using an operating system with no package management 2. Poor developer discipline, i.e. developers always trying to use the latest version of a package.

So now we have lots of poorly implemented language package managers, docker containers on top being used as another package management layer (even though that's not their primary purpose but many people use the like that) and the security implications of pulling in lots of random dependencies without any audit.

Developing towards a stable base like Debian would not be a pancea, but alliviate the problems by at least placing another audit layer in between.

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

#447

Post by typpilol »

simiones wrote: post #325
Tadpole9181 wrote: post #296

Earlier quoted context omitted.

`npm install` uses a lockfile by default and will not change versions. No, not transitives either. You would have to either manually change `package.json` or call `npm update`. You'd have to go out of your way to make your project as bad as you're describing.

No, this is just wrong. It might indeed use package-lock.json if it matches your node_modules (so that running `npm install` multiple times won't download new versions). But if you're cloning a repo off of GitHub and running npm install for the first time (which a CI setup might do), it will take the latest deps from package.json and update the package-lock.json - at least this is what I've found many responses onlin…

That's not true. Ci will never take new versions from your lock file.

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

#448

Post by dboreham »

rectang wrote: post #423
ncruces wrote: post #381

Earlier quoted context omitted.

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

It's not unreasonable to trust large numbers of trustworthy dependency authors. What we lack are the institutions to establish trust reliably. If packages had to be cryptographically signed by multiple verified authors from a per-organization whitelist in order to enter distribution, that would cut down on the SPOF issue where compromising a single dev is enough to publish multiple malware-infested packages.

Problem is that beyond some threshold number of authors, the probability they're all trustworthy falls to zero.

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

#449

Post by eschneider »

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…

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.

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

#450

Post by pier25 »

nbf_1995 wrote: post #440
pier25 wrote: post #432

So glad I left JS for backend last year. It was a big effort switching to a new language and framework (still is) but it looks like so far the decision was worth it. I'm still looking at Bun and all the effort they're doing with built-in APIs to reduce (and hopefully eliminate) third party deps. I would prefer using TS for the whole stack if possible but not at the expense of an insecure backend ecosystem.

Just curious, what did you switch to?

dotnet
Post reply on HN