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

481–490 of 1001 posts

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

#481

Post by banku_brougham »

dboreham wrote: post #445
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.

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

>This is what happens when nobody pays for anything and nobody feels they have a duty to do good work for free.

Weirdly, some of the worst CVE I can think of were with enterprize software.

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

#482

Post by LtWorf »

ronsor wrote: post #331
thewebguyd wrote: post #320

Earlier quoted context omitted.

Why even put a package download count on it? Just require it for everything submitted to NPM. It's not hard.

Because then it's extra hassle and expense for new developers to publish a package, and we're trying to keep things decentralized.

Download counters are completely useless. I could download your package 2 million times in under a minute and cause you to need the 2FA.

And true 2FA means you can't automate publishing from github's CI. Python is going the other direction. There is a fake 2FA that is just used to generate tokens and there is a preferential channel to upload to pypi via github's CI.

But in my opinion none of this helps with security. But it does help to de-anonymise the developers, which is probably what they really want to do, without caring if those developers get hacked and someone else uses their identity to do uploads.

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

#483

Post by vips7L »

acomjean wrote: post #344
foobarbecue wrote: post #274

Earlier quoted context omitted.

Can't help noticing, in the original article: > The entire attack design assumes Linux or macOS execution environments, checking for os.platform() === 'linux' || 'darwin'. It deliberately skips Windows systems If I were the conspiracy-minded sort I might jump to some wild conclusions here.

I’m using windows again. By default windows has “power shell” which is not at all like bash and is (how do I say this diplomatically)… wanting. I mean it says something the developed the Linux Subsystem for Windows, but it’s an optional install.

Powershell is amazing. Just don't expect it to be posix. Using objects and structured data is leagues better than string parsing in posix shells imo.

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

#484

Post by pragma_x »

So, other packaging environments have a tendency to slow down the rate of change that enters the user's system. Partly through the labor of re-packaging other people's software, but also as a deliberate effort. For instance: Ubuntu or RedHat.

Is anyone doing this in a "security as a service" fashion for JavaScript packages? I imagine a kind of package escrow/repository that only serves known secure packages, and actively removes known vulnerable ones.

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

#485

Post by herpdyderp »

ants_everywhere wrote: post #465
herpdyderp wrote: post #394

Earlier quoted context omitted.

With repos and workflows being infected, wouldn't a CI-only deploy not help?

The malware is modifying files and adding github workflows. If your builds are reproducible and run from committed code then the only way to add the post install script is if the maintainer reviews and accepts the commit that adds it. Similarly with the github workflow branch. And if your CI is building and releasing in a sandboxed hermetic environment, then the sandboxes that build and release don't need credentials…

> The malware is modifying files and adding github workflows. If your builds are reproducible and run from committed code

Exactly: it can simply commit its code and trigger a CI-only GitHub Actions deploy with no input from the maintainer at all.

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

#486

Post by spion »

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

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

#487

Post by btown »

zelphirkalt wrote: post #457
Ajedi32 wrote: post #420

Earlier quoted context omitted.

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.

Most dependencies do much more than we need from them. Often it means we only need one or a few functions from them. This means one doesn't need to rewrite whole dependencies usually. Don't use dependencies for things you can trivially write yourself, and use them for cases where it would be too much work to write yourself.

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 install Lodash and let your build step shake out any unused code, rather than importing 5 new dependencies, each with far fewer eyes and release-management best practices than the Lodash maintainers have.

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

#488

Post by philipwhiuk »

bennyg wrote: post #466
Ajedi32 wrote: post #420

Earlier quoted context omitted.

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.

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

Do you have any evidence it wouldn't just make up code.

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

#489

Post by duped »

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 that you need to use.

The only time this philosophy has bitten me was in an older project where I had to convince a PM who built some node project on their machine that the vulnerability warnings were not actually issues that affected our project.

Edit: because I don't want to reply to three things with the same comment - what are you using for dependencies where a) you require frequent updates and b) those updates are really hard?

Like for example, I've avoided updating node dependencies that have "vulnerabilities" because I know the vuln doesn't affect me. Rarely do I need to update to support new features because the dependency I pick has the features I need when I choose to use it (and if it only supports partial usage, you write it yourself!). If I see that a dependency frequently has bugs or breakages across updates then I stop using it, or freeze my usage of it.

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

#490

Post by philipwhiuk »

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

Aren't they found quickly because people upgrade quickly?
Post reply on HN