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

261–270 of 1001 posts

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

#261

Post by pixl97 »

rs999gti wrote: post #238
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…

> supply chain attacks You all really need to stop using this term when it comes to OSS. Supply chain implies a relationship, none of these companies or developers have a relationship with the creators other than including their packages. Call it something like "free code attacks" or "hobbyist code attacks."

A supply chain can have hobbyists, there's no particular definition that says everyone involved must be a professional registered business.

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

#262

Post by perlgeek »

quotemstr wrote: post #160

Jesus Christ. Another one? What the fuck? This isn't a JavaScript problem. What, structurally, stops the same thing happening to PyPI? Or the Rust ecosystem? Or Lisp via QuickLisp? Or CPAN? This whole mess was foreseeable. So what's to be done? Look. Any serious project needs to start vendoring its dependencies. People should establish big, coarse grained meta-distributions like C++ Boost that come from a trustable a…

> This isn't a JavaScript problem. What, structurally, stops the same thing happening to PyPI? Or the Rust ecosystem? Or Lisp via QuickLisp? Or CPAN?

For one, NPM has a really sprawling ecosystem where it's normal to have many dependencies.

I remember that I once tried to get started with angular, and I did an "init" for an empty project and "compile", and suddenly had half a gigabyte of code lying in my directory.

This means that there is a high number of dependencies that are potential targets for a supply chain attack.

I just took a look at our biggest JS/Typescript project at work, it comes in at > 1k (recursive) NPM dependencies. Our biggest Python project has 78 recursive dependencies. They are of comparable size in terms of lines of code and total development time.

Why? Differences in culture, as well as python coming with more "batteries included", so there's less need for small dependencies.

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

#263

Post by simiones »

WD-42 wrote: post #190
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…

Javascript doesn't have a standard library, until it does the 170 million[1] weekly downloads of packages like UUID will continue. You can't expect people to re-write everything over and over. [1] https://www.npmjs.com/package/uuid

That's not the problem. There is a cultural (and partly technical) aversion in JavaScript to large libraries - this is where the issue comes from. So, instead of having something like org.apache.commons in Java or Boost in C++ or Posix in C, larger libraries that curate a bunch of utilities missing from the standard library, you get an uncountable number of small standalone libraries.

I would bet that you'll find a third party `leftpad` implementation in org.apache.commons or in Spring or in some other collection of utils in Java. The difference isn't the need for 3rd party software to fix gaps in the standard library - it's the preference for hundreds of small dependencies instead of one or two larger ones.

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

#264

Post by pixl97 »

bdcravens wrote: post #75
koakuma-chan wrote: post #43

Earlier quoted context omitted.

Until you need to write JavaScript?

Then write it. Javascript itself isn't the problem, naive third-party dependencies are.

Developers are perfectly fine with writing insecure JS all by themselves.

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

#265

Post by [deleted] »

WD-42 wrote: post #190
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…

Javascript doesn't have a standard library, until it does the 170 million[1] weekly downloads of packages like UUID will continue. You can't expect people to re-write everything over and over. [1] https://www.npmjs.com/package/uuid

[deleted]

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

#266

Post by simiones »

galaxyLogic wrote: post #241
kortilla wrote: post #188

Earlier quoted context omitted.

None of those security guarantees matter when you take out the sandbox, which is exactly what server-side JS does. The isolated context is gone and a single instance of code talking to an individual client has access to your entire database. It’s a completely different threat model.

So maybe the solution would be to sandbox Node.js? I'm not quite sure what that would mean, but if it solves the problem for browsers, why not for server?

You can't sandbox the code that is supposed to talk to your DB from your DB.

And even on client side, the sandboxing helps isolate any malicious webpage, even ones that are accidentally malicious, from other webpages and from the rest of your machine.

If malicious actors could get gmail.com to run their malicious JS on the client side through this type of supply-chain attack, they could very very easily steal all of your emails. The browser sandbox doesn't offer any protection from 1st party javascript.

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

#267

Post by cedws »

zachrip wrote: post #38
jbd0 wrote: post #15

I knew npm was a train wreck when I first used it years ago and it pulled in literally hundreds of dependencies for a simple app. I avoid anything that uses it like the plague.

I can tell a lot about a dev by the fact that they single out npm/js for this supply chain issue.

The JavaScript ecosystem has a major case of import-everything disease that acts as a catalyst for supply chain attacks. left-pad as one example of many.

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

#268

Post by eknkc »

theodorejb wrote: post #258
eknkc wrote: post #102

Earlier quoted context omitted.

Does that even matter? The malware could have been a JS code injected into the module entry point itself. As soon as you execute something that imports the package (which, you did install for a reason) the code can run. I don't think that many people sandbox their development environments.

It absolutely matters. Many people install packages for front-end usage which would only be imported in the browser sandbox. Additionally, a package may be installed in a dev environment for inspection/testing before deciding whether to use it in production. To me it's quite unexpected/scary that installing a package on my dev machine can execute arbitrary code before I ever have a chance to inspect the package to se…

I've been using pnpm and it does not run lifecycle scripts by default. Asks for confirmation and creates a whitelist if you allow things. Might be the better default.

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

#269

Post by chamomeal »

skydhash wrote: post #200
WD-42 wrote: post #190

Earlier quoted context omitted.

Javascript doesn't have a standard library, until it does the 170 million[1] weekly downloads of packages like UUID will continue. You can't expect people to re-write everything over and over. [1] https://www.npmjs.com/package/uuid

You have the DOM and Node APIs. Which I think cover more than C library or Common Lisp library. Adding direct dependencies is done by every project. The issue is the sprawling deps tree of NPM and JS culture. > You can't expect people to re-write everything over and over. That’s the excuse everyone is giving, then you see thousands of terminal libraries and calendar pickers.

When I was learning JS/node/npm as a total programming newbie, a lot of the advice online was basically “if you write your own version of foobar when foobar is already available as an npm package, you’re stupid for wasting your time”.

I’d never worked in any other ecosystem, and I wish I realized that advice was specific to JS culture

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

#270

Post by epolanski »

motorest wrote: post #222
epolanski wrote: post #108

Earlier quoted context omitted.

Why are people using React to write simple ecommerces? Why are React devs pulling object utils from lodash instead of reimplementing them?

> Why are people using React to write simple ecommerces? What leads you to believe React is not well suited to simple ecommerce sites?

1. It's a solution meant for highly interactive app-like websites, not static-content driven websites like ecommerces. React in this context is just the wrong tool for the problem that will give you a huge array of performance, bugs and ux problems.

2. Extensive ecommerce experience including Disney, Carnival Cruises, Booking, TUI, and some of the European leaders in real estate and professional home building tools among the others.

Post reply on HN