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

51–60 of 1001 posts

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

#51

Post by jddj »

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…

Is the difference between the number of dev dependencies for eg. VueJs (a JavaScript library for marshalling Json Ajax responses into UI) and Htmx (a JavaScript library for marshalling html Ajax responses into UI) meaningful?

There is a difference, but it's not an order of magnitude and neither is a true island.

Granted, deciding not to use JS on the server is reasonable in the context of this article, but for the client htmx is as much a js lib with (dev) dependencies as any other.

https://github.com/bigskysoftware/htmx/blob/master/package.j...

https://github.com/vuejs/core/blob/main/package.json

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

#52

Post by baq »

koakuma-chan wrote: post #43
petcat wrote: post #39

Earlier quoted context omitted.

Rendering template partials server-side and fetching/loading content updates with HTMX in the browser seems like the best of all worlds at this point.

Until you need to write JavaScript?

Which should be much less than what’s customary?

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

#53

Post by pjc50 »

diggan wrote: post #24
madeofpalk wrote: post #13

My main takeaway from all of these is to stop using tokens, and rely on mechanisms like OIDC to reduce the blast radius of a compromise. How many tokens do you have lying around in your home directory in plain text, able to be read by anything on your computer running as your user?

> How many tokens do you have lying around in your home directory in plain text, able to be read by anything on your computer running as your user? Zero? How many developers have plain-text tokens lying around on disk? Avoiding that been hammered into me from every developer more senior than me since I got involved with professional software development.

Isn't this quite hard to achieve on local systems, where you don't have a CI vault automation to help?

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

#54

Post by ants_everywhere »

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

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

#55

Post by jsiepkes »

palmfacehn wrote: post #20
gchamonlive wrote: post #2

We've seen many reports of supply chain attacks affecting NPM. Are these symptoms of operational complexity, which can affect any such service, or is there something fundamentally wrong with NPM?

Apparently Maven has 61.9M indexed packages. As Java has a decent standard lib, mini libs like leftpad are not contributing to this count. NPM has 3.1M packages. Many are trivially simple. Those stats would suggest that NPM has disproportionately more issues than other services. I would argue that is only one of the many issues with the JS/TS/NPM ecosystem. Many of the other problems have been normalized. The constan…

> Apparently Maven has 61.9M indexed packages.

Where did you see that number? Maven central says it has about 18 million [1] packages. Maybe with all versions of those 18 million packages there are about 62 million artifacts?

While the Java ecosystem is vastly larger, in Java (with Maven, Gradle, Bazel, etc.) it is not common to use really small libraries. So you end up with vastly less transitive dependencies in your projects.

[1] https://mvnrepository.com/repos/central

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

#56

Post by ehnto »

koakuma-chan wrote: post #43
petcat wrote: post #39

Earlier quoted context omitted.

Rendering template partials server-side and fetching/loading content updates with HTMX in the browser seems like the best of all worlds at this point.

Until you need to write JavaScript?

But that's the neat part, you don't!

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

#57

Post by tarruda »

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.

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

#58

Post by pjc50 »

killerstorm wrote: post #29
l___l wrote: post #10

Is there a theoretical framework that can prevent this from happening? Proof-carrying code?

Object-capability model / capability-based security. Do not let code to have access to things it's not supposed to access. It's actually that simple. If you implemented a function which formats a string, it should not have access to `readFile`, for example. Retrofitting it into JS isn't possible, though, as language is way too dynamic - self-modifying code, reflection, etc, means there's no isolation between modules.…

People have tried this, but in practice it's quite hard to do because then you have to start treating individual functions as security boundaries - if you can't readFile, just find a function which does it for you.

The situation gets better in monadic environments (can't readFile without the IO monad, and you cant' call anything which would read it).

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

#60

Post by Intermernet »

gchamonlive wrote: post #2

We've seen many reports of supply chain attacks affecting NPM. Are these symptoms of operational complexity, which can affect any such service, or is there something fundamentally wrong with NPM?

Just spit-balling here, but it seems that the problem is with the pushing to NPM, and distribution from NPM, rather than the concept of NPM. If NPM required some form of cryptographically secure author signing, and didn't distribute un-signed packages, then there is at least a chain of responsibility that can be followed.
Post reply on HN