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

411–420 of 1001 posts

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

#411

Post by kelnos »

noodlesUK wrote: post #299
btown wrote: post #252

Earlier quoted context omitted.

I'd like to think there are ways to do this and keep things decentralized. Things like: Once a package has more than [threshold] daily downloads for an extended period of time, it requires 2FA re-auth/step-up on two separate human-controlled accounts to approve any further code updates. Or something like: for these popular packages, only a select list of automated build systems with reproducible builds can push direc…

I think that we should impose webauthn 2fa on all npm accounts as the only acceptable auth method if you have e.g., more than 1 million total downloads. Someone could pony up the cash to send out a few thousand yubikeys for this and we'd all be a lot safer.

How would that work for CI release flows? I have my Rust crates, for example, set up to auto-publish whenever I push a tag to its repo.

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

#412

Post by Pet_Ant »

ncruces wrote: post #381
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…

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.

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

#413

Post by CraftThatBlock »

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

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

#414

Post by AnotherGoodName »

nromiun wrote: post #380
g42gregory wrote: post #369

Are Python packaging systems like pip exposed to the same risks? Is anybody looking at this?

Not to the same extent as NPM. Because Python has a good standard library and library authors are not deathly afraid of code duplication like JS devs, for example micro libraries like left-pad, is-even etc.

Also there’s more of a habit to release to the pre release channel for some time first.

I honestly think a forced time spent in pre release (with some emergency break glass where community leaders manually review critical hotfixes) could mitigate 99% of the issues here. Linux packages have been around for ever and have fewer incidents mainly because of the long dev->release channel cooking time.

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

#415

Post by computerex »

ncruces wrote: post #381
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…

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

Be that as it may, a system that can fail catastrophically will. Security shouldn't be left to choice.

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

#416

Post by gameman144 »

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…

> 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 pretty sensible.

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

#417

Post by matthew16550 »

Yasuraka wrote: post #292
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…

> NPM, Python, Rust, Go, Ruby all suffer from this problem, because they have centralized and open package repositories Can you point me to Go's centralized package repository?

https://pkg.go.dev/

Which works together with

https://proxy.golang.org/

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

#419

Post by LikesPwsh »

gedy wrote: post #370
weinzierl wrote: post #137

Earlier quoted context omitted.

In Rust we have cargo vet, where we share these audits and use them in an automated fashion. Companies like Google and Mozilla contribute their audits.

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.

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

#420

Post by Ajedi32 »

gameman144 wrote: post #416
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…

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

If it's not feasible to audit every single dependency, it's probably even less feasible to rewrite every single dependency from scratch. Avoiding that duplicated work is precisely why we import dependencies in the first place.
Post reply on HN