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

641–650 of 1001 posts

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

#641

Post by rectang »

WesolyKubeczek wrote: post #522
rectang wrote: post #423

Earlier quoted context omitted.

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.

"Find large numbers of trustworthy dependency authors in your neighborhood!" "Large numbers of trustworthy dependency authors in your town can't wait to show you their hottest code paths! Click here for educational livecoding sessions!"

I don't understand your critique.

Establishing a false identity well enough to fool a FOSS author or organization is a lot of work. Even crafting a spear phishing email/text campaign doesn't compare to the effort you'd have to put in to fool a developer well enough to get offered publishing privileges.

Of course it's possible, but so are beat-them-with-a-five-dollar-wrench attacks.

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

#642

Post by bennyg »

shakna wrote: post #529
bennyg wrote: post #466

Earlier quoted context omitted.

Sounds like the job for an LLM tool to extract what's actually used from appropriately-licensed OSS modules and paste directly into codebases.

Requiring you to audit both security and robustness on the LLM generated code. Creating two problems, where there was one.

I didn't say generate :) - in all seriousness, I think you could reasonably have it copy the code for e.g. lodash.merge() and paste it into your codebase without the headaches you're describing. IMO, this method would be practical for a majority of npm deps in prod code. There are some I'd want to rely on the lib (and its maintenance over time), but also... a sort function is a sort function.

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

#644

Post by halflife »

latexr wrote: post #636
btown wrote: post #487

Earlier quoted context omitted.

A brief but important point is that this primarily holds true in the context of rewriting/vendoring utilities yourself, not when discussing importing small vs. large dependencies. Just because dependencies do a lot more than you need, doesn't mean you should automatically reach for the smallest dependency that fits your needs. If you need 5 of the dozens of Lodash functions, for instance, it might be best to just ins…

The argument wasn’t to import five dependencies, one for each of the functions, but to write the five functions yourself . Heck, you don’t even need to literally write them, check the Lodash source and copy them to your code.

And then when node is updated and natively supports set intersections you would go back to your copied code and fix it?

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

#645

Post by biggusdickus69 »

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

Earlier quoted context omitted.

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

The time upgrading is not linear, it’s exponential. If it hurts, do it more often! https://martinfowler.com/bliki/FrequencyReducesDifficulty.ht...

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

#646

Post by Liskni_si »

the8472 wrote: post #451
Liskni_si wrote: post #340

Earlier quoted context omitted.

In the Rust ecosystem, you only publish lock files for binary crates. So yeah then you get churn like https://github.com/cargo-bins/cargo-binstall/releases/tag/v1... bumping transitive deps, but this churn/noise doesn't exist for library crates - because the lock file isn't published for them.

lib crates have been checking in their Cargo.lock for a while now. https://github.com/rust-lang/cargo/pull/12382

That Cargo.lock will only be used for the library's own CI though (and also for development if you git clone it). It will not be used by downstream dependencies at all.

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

#647

Post by mandevil »

latexr wrote: post #636
btown wrote: post #487

Earlier quoted context omitted.

A brief but important point is that this primarily holds true in the context of rewriting/vendoring utilities yourself, not when discussing importing small vs. large dependencies. Just because dependencies do a lot more than you need, doesn't mean you should automatically reach for the smallest dependency that fits your needs. If you need 5 of the dozens of Lodash functions, for instance, it might be best to just ins…

The argument wasn’t to import five dependencies, one for each of the functions, but to write the five functions yourself . Heck, you don’t even need to literally write them, check the Lodash source and copy them to your code.

This might be fine for some utility functions which you can tell at a glance have no errors, but for anything complex, if you copy you don't get any of the bug/security fixes that upstream will provide automatically. Oh, now you need a shim of this call to work on the latest Chrome because they killed an api- you're on your own or you have to read all of the release notes for a dependency you don't even have! But taking a dependency on some other library is, as you note, always fraught. Especially because of transitive dependencies, you end up having quite a target surface area for every dep you take.

Whether to take a dependency is a tricky thing that really comes down to engineering judgement- the thing that you (the developer) are paid to make the calls on.

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

#649

Post by hedora »

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…

I recently started using npm for an application where there’s no decent alternative ecosystem.

The signal desktop app is an electron app. Presumably it has the same problem.

Does anyone know of any reasonable approaches to using npm securely?

“Reduce your transitive dependencies” is not a reasonable suggestion. It’s similar to “rewrite all the Linux kernel modules you need from scratch” or “go write a web browser”.

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

#650

Post by biggusdickus69 »

cmckn wrote: post #639
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…

> 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 The problem with this approach is you need a certain number of guinea pigs on the bleeding edge or the outcome is the same (just delayed). There is no way for anyone involved to ensure that balance is maintained. Reducing your surface area is a much…

Not necessarily, some supply chain compromises are detected within a day by the maintainers themselves, for example by their account being taken over. It would be good to mitigate those at least.
Post reply on HN