Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

Post reply on HN
Print view View original

401–410 of 797 posts

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#401

Post by throwawayffffas »

junon wrote: post #193
throwawayffffas wrote: post #147

> Upon execution, the malware downloads and runs TruffleHog to scan the local machine, stealing sensitive information such as NPM Tokens, AWS/GCP/Azure credentials, and environment variables. That's a wake up call to harden your operations. NPM Tokens, AWS/GCP/Azure credentials have no reason to be available in environments where packages may be installed. The same goes for sensitive environment variables.

That's the goal, but it's not feasible in e.g. professional settings. Much easier said than done, unfortunately.

I agree it's hard. But it's actually easier in professional settings. There are funds and you don't have an excuse to be lazy.

At minimum whatever you are working on should be built in docker. The package installation then would happen during the image build step. Yes it's easy to break out of the isolation environment but i am betting this malware does not.

NPM tokens should exist in some configuration/secret management solution not on your home directory. Devs have no business holding the NPM tokens. Same goes for sensitive environment variables they have no business existing on dev laptops or even the pipeline build steps (where package installation should happen).

AWS etc credentials / tokens are harder to secure since there are legit reasons for existing in dev laptops.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#402

Post by hedora »

herpdyderp wrote: post #301
efortis wrote: post #261

Mitigate this attack vector by adding: ignore-scripts=true to your .npmrc https://blog.uxtly.com/getting-rid-of-npm-scripts

Also add it to ~/.npmrc!

So, I do this because it's universally recommended, but why does it help?

Can't they just jam the malware into the package itself? It runs with the same permissions on my machine (in unit tests, node servers, etc).

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#403

Post by HighGoldstein »

latentsea wrote: post #277
metaltyphoon wrote: post #225

Earlier quoted context omitted.

This is a reason why so many enterprises use C#. Most of the time you just use Microsoft made libraries and rarely brings in 3rd party.

Having worked on four different enterprise grade C# codebases, they most certainly have plenty of 3rd party dependencies. It would absolutely be the exception to not have 3rd party dependencies.

Yes, but the 3rd party dependencies tend to be conveniences rather than foundational. Easier mapping, easier mocking, easier test assertions, so a more security minded company can very easily just disallow their use without major impact. If it's something foundational to your project then what you're doing is probably somewhat niche. Most of the time there's some dependency from Microsoft that's rarely worse enough to justify using the 3rd party one.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#404

Post by chuckadams »

pas wrote: post #353
chuckadams wrote: post #322

Earlier quoted context omitted.

> It's not "node" or "Javascript" the problem, it's this convenient packaging model. That and the package runtime runs with all the same privileges and capabilities as the thing you're building, which is pretty insane when you think about it. Why should npm know anything outside of the project root even exists, or be given the full set of environment variables without so much as a deny list, let alone an allow list?…

pnpm (maybe yarn too?) requires explicit allowlisting of build scripts, hopefully npm will do the same eventually > security model yep, some kind of seccomp or other kind of permission system for modules would help a lot. (eg. if the 3rd party library is parsing something and its API only requires a Buffer as input and returns some object then it could be marked "pure", if it supports logging then that could be also…

For all the other things I like about yarn, it still executes build scripts willy-nilly, so I am looking at switching to pnpm. I'm sure my $work is going to love me changing up the build toolchain again... PHP's composer on the other hand requires an allowlist in the project's composer.json. I never would have thought PHP would be the one to be getting stuff like this right.

Still, I think the "allow-scripts" section or whatever it's called should be named "allow-unrestricted-access-to-everything". Or maybe just stick "dangerously-" in front, I dunno, and drop it when the mechanism is capable of fine-grained privileges.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#405

Post by hedora »

westoque wrote: post #12

a concern i have is that it's only a matter of time before a similar attack is done to electron based apps (which also have packages installed using npm). probably worse because it's installed in your computer and can potentially get any information especially given admin privileges.

I'd really like to know how signal deals with this. It's supposedly super secure + stuff, but it's built on top of this ecosystem.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#406

Post by Zettroke »

SAI_Peregrinus wrote: post #368
wongarsu wrote: post #100

Earlier quoted context omitted.

I wouldn't call the Rust stdlib "small". "Limited" I could agree with. On the topics it does cover, Rust's stdlib offers a lot . At least on the same level as Python, at times surpassing it. But because the stdlib isn't versioned it stays away from everything that isn't considered "settled", especially in matters where the best interface isn't clear yet. So no http library, no date handling, no helpers for writing ma…

> But because the stdlib isn't versioned I honestly feel like that's one of Rust's biggest failings. In my ideal world libstd would be versioned, and done in such a way that different dependencies could call different versions of libstd, and all (sound/secure) versions would always be provided. E.g. reserve the "std" module prefix (and "core", and "alloc"), have `cargo new` default to adding the current std version i…

I'm afraid it won't work. The point of std lib is to be universal connection for all the libraries. But with versioned std I just can't see how can you have DateTime in std1, DateTime in std2 and use them interchangeably, for example being able to pass std2::DateTime to library depending on std1 etc. Maybe conversion methods, but it get really complicated really quickly

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#407

Post by shadymoney »

This is why I am not a huge fan of separate package managers for libraries, such as in the case of rust, or node. The C style of sharing deps. couldn't really be simpler as just including the headers in your Makefile.

We really don't need more package managers other than the ones provided by your operating system, but I dunno maybe its just me.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#408

Post by SkyPuncher »

plomme wrote: post #346
darkamaul wrote: post #26

The "use cooldown" [0] blog post looks particularly relevant today. I'd argue automated dependency updates pose a greater risk than one-day exploits, though I don't have data to back that up. That's harder to undo a compromised package already in thousands of lock files, than to manually patch a already exploited vulnerability in your dependencies. [0] https://blog.yossarian.net/2025/11/21/We-should-all-be-using...

Why not take it further and not update dependencies at all until you need to because of some missing feature or systems compatibility you need? If it works it works.

This works until you consider regular security vulnerability patching (which we have compliance/contractual obligations for).

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#410

Post by MatthiasDev »

gnfargbl wrote: post #95
sph wrote: post #7

Earlier quoted context omitted.

It's not "node" or "Javascript" the problem, it's this convenient packaging model. This is gonna ruffle some feathers, but it's only a matter of time until it'll happen on the Rust ecosystem which loves to depend on a billion subpackages, and it won't be fault of the language itself. The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a ca…

I'm a huge Go proponent but I don't know if I can see much about Go's module system which would really prevent supply-chain attacks in practice. The Go maintainers point [1] at the strong dependency pinning approach, the sumdb system and the module proxy as mitigations, and yes, those are good. However, I can't see what those features do to defend against an attack vector that we have certainly seen elsewhere: projec…

A big thing is that Go does not install the latest version of transitive dependencies. Instead it uses Minimal version selection (MVS), see https://go.dev/ref/mod#minimal-version-selection. I highly recommend reading the article by Russ Cox mentioned in the ref. This greatly decreases your chances of being hit by malware released after a package is taken over.

In Go, access to the os and exec require certain imports, imports that must occur at the beginning of the file, this helps when scanning for malicious code. Compare this JavaScript where one could require("child_process") or import() at any time.

Personally, I started to vendor my dependencies using go mod vendor and diff after dependency updates. In the end, you are responsible for the effect of your dependencies.

Post reply on HN