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

461–470 of 1001 posts

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

#461

Post by thepill »

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

bun is also working on it: https://github.com/oven-sh/bun/issues/22679

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

#462

Post by 2muchcoffeeman »

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…

Have we all forgotten the left-pad incident?

This is an eco system that has taken code reuse to the (unreasonable) extreme.

When JS was becoming popular, I’m pretty sure every dev cocked an eyebrow at the dependency system and wondered how it’d be attacked.

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

#463

Post by rectang »

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

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

It's true that smuggling multiple identities into the whitelist is one attack vector, and one reason why I said "cut down" rather than "eliminate". But that's not easy to do for most organizations.

For what it's worth, back when I was active at the ASF we used to vote on releases — you needed at least 3 positive votes from a whitelist of approved voters to publish a release outside the org and there was a cultural expectation of review. (Dunno if things have changed.) It would have been very difficult to duplicate this NPM attack against the upstream ASF release distribution system.

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

#464

Post by tetha »

spankalee wrote: post #186
jeswin wrote: post #167

Earlier quoted context omitted.

Traditional JS is actually among the safest environments ever created. Every day, billions of devices run untrusted JS code, and no other platform has seen sandboxed execution at such scale. And in nearly three decades, there have been very few incidents of large successful attacks on browser engines. That makes the JS engine derived from browsers the perfect tool to build a server side framework out of. However, pro…

Sandboxing doesn't do any good if the malicious code and target data are in the same sandbox, which is the whole point of these supply-chain attacks.

But if we think about a release publishing chain like a BSD process separation, why do they have to be?

Sure, there will be a step/stage that will require access to NPM publish credentials to publish to NPM. But why does this stage need to execute any code except a very small footprint of vetted code? It should just pickup a packaged, signed binary and move it to NPM.

The compilation/packaging step on the other hand doesn't need publishing rights to NPM. Ideally, it should only get a filesystem with the sources, dependencies and a few shared libraries and /sys or /proc dependencies it may need to function. Why does some dependency downloading need access to your entire filesystem? Maybe it needs some allowed secrets, but eh.

It's certainly a lot of change into existing pipelines and ideas, and it's certainly possible to poke holes into there if you want things to be easy. But it'd raise the bar quite a bit.

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

#465

Post by ants_everywhere »

herpdyderp wrote: post #394
ants_everywhere wrote: post #54

This seems like something that can be solved with reproducible builds and ensuring you only deploy from a CI system that verifies along the way. In fact this blog post appears to be advertising for a system that secures build pipelines. Google has written up some about their internal approach here: https://cloud.google.com/docs/security/binary-authorization-...

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 like AWS_ACCESS_KEY because they can't depend on data from the network. You need credentials for deploying and signing, but they don't need to be present during build time.

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

#466

Post by bennyg »

Ajedi32 wrote: post #420
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…

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.

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

#467

Post by g42gregory »

AnotherGoodName wrote: post #414
nromiun wrote: post #380

Earlier quoted context omitted.

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.

Forced time in pre-release sounds like a really good idea.

Can somebody drive this up the chain to people who administer npm?

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

#468

Post by zelphirkalt »

tarruda wrote: post #57
codemonkey-zeta wrote: post #31

I'm coming to the unfortunate realizattion that supply chain attacks like this are simply baked into the modern JavaScript ecosystem. Vendoring can mitigate your immediate exposure, but does not solve this problem. These attacks may just be the final push I needed to take server rendering (without js) more seriously. The HTMX folks convinced me that I can get REALLY far without any JavaScript, and my apps will probab…

AFAICT, the only thing this attack relies on, is the lack of scrutiny by developers when adding new dependencies. Unless this lack of scrutiny is exclusive to JavaScript ecosystem, then this attack could just as well have happened in Rust or Golang.

At least in the JS world there are more people (often also more inexperienced people) who will add a dependency willy-nilly. This is due to many people starting out with JS these days.

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

#469

Post by skybrian »

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…

When using Go, you don't get updated indirect dependencies until you update a direct dependency. It seems like a good system, though it depends on your direct dependencies not updating too quickly.

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

#470

Post by zahlman »

curtisf wrote: post #425
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.

This is true to the extent that you actually _use_ all of the features of a dependency. You only need to rewrite what you use, which for many (probably most) libraries will be 1% or less of it

Indeed. About 26% of the disk space for a freshly-installed copy of pip 25.2 for Python 3.13 comes from https://pypi.org/project/rich/ (and its otherwise-unneeded dependency https://pypi.org/project/Pygments/), "a Python library for rich text and beautiful formatting in the terminal", hardly any of the features of which are relevant to pip. This is in spite of an apparent manual tree-shaking effort (mostly on Pygments) — a separate installed copy of rich+Pygments is larger than pip. But even with that attempt, for example, there are hundreds of kilobytes taken up for a single giant mapping of "friendly" string names to literally thousands of emoji.

Another 20% or more is https://pypi.org/project/requests/ and its dependencies — this is an extremely popular project despite that the standard library already provides the ability to make HTTPS connections (people just hate the API that much). One of requests' dependencies is certifi, which is basically just a .pem file in Python package form. The vendored requests has not seen any tree-shaking as far as I can tell.

This sort of thing is a big part of why I'll be able to make PAPER much smaller.

Post reply on HN