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

831–840 of 1001 posts

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

#831

Post by david-james-2 »

I set "ignore-scripts=true" (https://docs.npmjs.com/cli/v11/using-npm/config#ignore-scrip...) in npmrc(5). This changed the defaults for npm(1).

The Semgrep blog under "Additional NPM Registry Security Advice / Reducing Run Scripts" says "reducing" not "ignoring". I need to check if there are still "run scripts" even with this setting.

Also I need to check if there is the same class of vulnerabilities in other package managers I use, like emacs(1) (M-x package-install), mvn(1) (Maven, Java), clj(1) (deps.edn, Clojure), luarocks(1) (Lua), deps(1) (deps.fnl, Fennel), nbb(1) (deps.edn, Node.js babashka). Although some do not have "run scripts" feature, I need to make sure.

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

#832

Post by Sankozi »

hacker_homie wrote: post #627

I’m not sure language package mangers were a good idea at all. Dependencies were supposed to be painful. If the language needed some functionality built in it was supposed to go into the standard library, I understand that for JS this isn’t feasible.

It is not package managers. It is due to the poor NPM ecosystem: lots of crappy packages (like left-pad), auto updates, lots of dependencies, post install scripts, insecure language.

These security problems happen much less often in other ecosystems. There is nothing even remotely as bad as NPM.

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

#833

Post by VPenkov »

theodorejb wrote: post #276

It's crazy to me that npm still executes postinstall scripts by default for all dependencies. Other package managers (Pnpm, Bun) do not run them for dependencies unless they are added to a specific allow-list. Composer never runs lifecycle scripts for dependencies. This matters because dependencies are often installed in a build or development environment with access to things that are not available when the package…

It does not, since version 11:

https://docs.npmjs.com/cli/v11/using-npm/changelog#1100-pre0...

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

#834

Post by arccy »

LelouBil wrote: post #606
theodorejb wrote: post #276

It's crazy to me that npm still executes postinstall scripts by default for all dependencies. Other package managers (Pnpm, Bun) do not run them for dependencies unless they are added to a specific allow-list. Composer never runs lifecycle scripts for dependencies. This matters because dependencies are often installed in a build or development environment with access to things that are not available when the package…

I'm also wondering why huge scale attacks like this don't happen for other package managers. Like, for rust, you can have a build.rs file that gets executed when your crate is compiled, I don't think it's sandboxed. Or also on other languages that will get run on development machines, like python packages (which can trigger code only on import), java libraries, etc... Like, there is the post install script issue or c…

for the same reason that scams are kind of obvious if you care to look: use of js / npm is an automatic filter for a more clueless target.

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

#835

Post by arccy »

whynotmaybe wrote: post #205
GuB-42 wrote: post #140

> Shai Hulud Clever name... but I would have expected malware authors to be a bit less obvious. They literally named their giant worm after a giant worm. > At the core of this attack is a ~3.6MB minified bundle.js file Yep, even malware can be bloated. That's in the spirit of NPM I guess...

Malwares have to follow Moore's law, tequila virus was ~2.6kb in 1991.

not quite moore's law, growth at only 1.226x per year

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

#836

Post by 63stack »

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…

A log4j level vulnerability happens again. Do you need 10 minutes to update? 1 hour? 1 day? 1 week? Multiple months? The more you are drifting behind on updates, the worse it gets, which also affects every one of your users, your business, and might be the end of your project.

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

#837

Post by arccy »

pragma_x wrote: post #484

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

Google has Assured Open Source for Python / Java https://cloud.google.com/security/products/assured-open-sour...

Some other vendors do AI scanning

I doubt anyone would want to touch js packages with manual review.

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

#838

Post by tjpnz »

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…

Easier said than done when your ecosystem of choice took the Unix philosophy of doing one thing well, misinterpreted it and then drove it off a cliff. The dependency tree of a simple Python service is incomparable to a Node service of similar complexity.

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

#839

Post by arccy »

zarzavat wrote: post #308
hannob wrote: post #30

Earlier quoted context omitted.

It's actually relatively simple. Adding dependencies comes with advantages and downsides. You need to strike a balance between them. External libraries can help implement things that you better don't implement yourself, so the answer is certainly not "no dependencies". But there are downsides and risks, and the risks grow with the number of dependencies. In the world of NPM, people think those simple truths don't app…

You can't put this all on the users. The JS/node/npm projects have been mismanaged since the start. node should have shipped "batteries included" after the left-pad incident. There was a boneheaded attachment to small stdlib, which you could put down to youthful innocence, except that it's been almost 10 years. The TC39 committee which controls the design of JS stdlib and the node maintainers basically both act like…

you can't just blame it on the platform. if the users had half a brain they'd come settle on an external "standard" library, a bit like C++ Boost. but no, everyone wants to pad their cv with a thousand packages.

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

#840

Post by ClikeX »

halflife wrote: post #644
latexr wrote: post #636

Earlier quoted context omitted.

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?

If you won't, do you expect the maintainer of some micro package to do that?
Post reply on HN