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

791–800 of 1001 posts

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

#791

Post by throwawayqqq11 »

abrookewood wrote: post #659
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…

The article explicitly mentions a way to do this: Use NPM Package Cooldown Check The NPM Cooldown check automatically fails a pull request if it introduces an npm package version that was released within the organization’s configured cooldown period (default: 2 days). Once the cooldown period has passed, the check will clear automatically with no action required. The rationale is simple - most supply chain attacks ar…

This attack was only targeting user environments.

Having secrets in a different security context, like root/secretsuser-owned secret files only accessible by the user for certain actions (the simplest way would be eg. sudoers file white listing a precise command like git push), which would prevent arbitrary reads of secrets.

The other part of this attack, creating new github actions, is also a privilege, normal users dont need to exercise that often or unconstrained. There are certainly ways to prevent/restrict that too.

All this "was a supply chain attack" fuzz here is IMO missing the forest for the trees. Changing the security context for these two actions is easier to implement than supply chain analysis and this basic approach is more reliable than trusting the community to find a backdoor before you apply the update. Its security 101. Sure, there are post-install scripts that can attack the system but that is a whole different game.

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

#792

Post by 2muchcoffeeman »

lodovic wrote: post #772
pxc wrote: post #750

Earlier quoted context omitted.

> There's also the flavor of frontend developer that came from the backend and sneers at actually having to learn frontend because "it's not real development" What kind of code does this developer write?

Usually they write only prompts and then accept whatever is generated, ignoring all typing and linting issues

Prompts? React and Angular came out over 10 years ago. The left pad incident happened in 2016.

Let me assure you, devs were skeptical about all this well before AI.

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

#793

Post by catlifeonmars »

duped wrote: post #489
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…

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…

That works fine if you have few dependencies (obviously this is a good practice) and you have time to vet all updates and determine whether a vulnerability impacts your particular code, but that doesn’t scale if you’re a security organization at, say, a small company.

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

#794

Post by cmckn »

biggusdickus69 wrote: post #650
cmckn wrote: post #639

Earlier quoted context omitted.

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

In that specific scenario, sure; but I don't think that's a meaningful guardrail for a business.

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

#795

Post by whstl »

wongarsu wrote: post #657
zelphirkalt wrote: post #475

Earlier quoted context omitted.

> This is an eco system that has taken code reuse to the (unreasonable) extreme. Not even that actually. Actually the wheel is reinvented over and over again in this exact ecosystem. Many packages are low quality, and not even suitable to be reused much.

The perfect storm of on the one side junior developers who are afraid of writing even trivial code and are glad if there's a package implementing functionality that can be done in a one-liner, and on the other side (often junior) developers who want to prove themselves and think the best way to do that is to publish a successful npm package

People pushing random throwaway packages is not the issue.

A lot of the culture is built by certain people who make a living out of package maximalism.

More packages == more eyballs == more donations.

They have an agenda that small packages are good and made PRs into popular packages to inject their junk into the supply chain.

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

#796

Post by SCdF »

snickerbockers wrote: post #774

I try to stay as far from web development as possible in my programming career (kernel/drivers and most recently reverse engineering) so maybe I'm ill-informed here but this npm thing seems to be uniquely terrible at security and i cannot fathom why the entire web seems to be automatically downloading updates from it and pushing them into production with no oversight. I've always worked at companies where we use thir…

A lot of it is just that it's at the local maximum of popularity and relative user inexperience, so it's the juiciest target.

But also, npm was very much (like js you could argue) vibed into existence in many ways, eg with the idea of a lock file (eg reproducible builds) _at all_ taking a very long time to take shape.

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

#797

Post by [deleted] »

throwawayqqq11 wrote: post #791
abrookewood wrote: post #659

Earlier quoted context omitted.

The article explicitly mentions a way to do this: Use NPM Package Cooldown Check The NPM Cooldown check automatically fails a pull request if it introduces an npm package version that was released within the organization’s configured cooldown period (default: 2 days). Once the cooldown period has passed, the check will clear automatically with no action required. The rationale is simple - most supply chain attacks ar…

This attack was only targeting user environments. Having secrets in a different security context, like root/secretsuser-owned secret files only accessible by the user for certain actions (the simplest way would be eg. sudoers file white listing a precise command like git push), which would prevent arbitrary reads of secrets. The other part of this attack, creating new github actions, is also a privilege, normal users…

[deleted]

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

#798

Post by hinkley »

0xbadcafebee wrote: post #583
gchamonlive wrote: post #2

We've seen many reports of supply chain attacks affecting NPM. Are these symptoms of operational complexity, which can affect any such service, or is there something fundamentally wrong with NPM?

With Javascript, yes, but also with all programming-language package managers and software development culture in general. There's too huge of an attack surface, and virtually no attack mitigation. It's a free for all. These are solvable problems, though. Distros have been doing it the right way for decades, and we could do it even better than that. But being lazy is easier. Until people are forced to improve - or th…

This has been brewing for a long time. Maven, CPAN before it.

Maybe some of these systems have better protection from counterfeiting, and probably they all should. But as the number of packages you use goes up, the surface area does too. As a Node developer the… permissiveness of the culture has always concerned me.

The trick with playing with fire is understanding how fire works, respecting it, and keeping the tricks small. The bigger you go, the more the danger.

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

#799

Post by wolvesechoes »

hedora wrote: post #649
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”.

> “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”.

Oh please, do not compare writing bunch of utilities for you "app" with writing a web browser.

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

#800

Post by lukan »

LtWorf wrote: post #601
zelphirkalt wrote: post #473

Earlier quoted context omitted.

Though you will see the code at least, when you are copy pasting it and if it is really only a few lines, you may be able to review it. Should review it of course.

If it's that little review the dependency.

The difference is, the dependency can change and is usually way harder to audit. Subfolders in subfolder, 2 lines here in a file, 3 line there vs locking at some files and check what they do.
Post reply on HN