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

231–240 of 1001 posts

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

#231

Post by codazoda »

progbits wrote: post #220
m4r71n wrote: post #203

Earlier quoted context omitted.

Since so many vendors discovered these packages seemingly independently, you'd think that they would share those mechanisms with NPM itself so that those packages would never be published in the first place. But I guess that removes their ability to sell an "early alert" mechanism through their offerings...

NPM is owned by github/microsoft. I'm sure they could afford to buy one of these products or just build their own, but clearly security is not a thing they care about.

Somehow I didn't realize GitHub purchased npm in 2020. GitHub is the second word on npmjs.org. How did I not notice?

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

#232

Post by codazoda »

augzodia wrote: post #173
cddotdotslash wrote: post #170

I wonder who actually discovered this attack? Can we credit them? The phrasing in these posts is interesting, with some taking direct credit and others just acknowledging the incident. Aikido says: > We were alerted to a large-scale attack against npm... Socket says: > Socket.dev found compromised various CrowdStrike npm packages... Ox says: > Attackers slipped malicious code into new releases... Safety says: > The S…

OP article says: > The incident was discovered by @franky47, who promptly notified the community through a GitHub issue.

Points to this, which does look like the first mention.

https://github.com/scttcper/tinycolor/issues/256

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

#233

Post by jmull »

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

FYI, there's crypto.randomUUID()

That's built in to server side and browser.

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

#234

Post by koakuma-chan »

johnisgood wrote: post #210
koakuma-chan wrote: post #133

Earlier quoted context omitted.

> What's your point? Just defending Rust. > 5 remaining dependencies have lots of dependencies of their own. Mostly well-known crates like rayon, crossbeam, tracing, etc.

You cannot defend Rust if this is reality. Any Rust project I have ever compiled pulled in over 1000 dependencies. Recently it was Zed with its >2000 dependencies.

I think it's justified for Zed. It does a lot of things.

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

#236

Post by motorest »

diggan wrote: post #9
motorest wrote: post #5

Earlier quoted context omitted.

> New day, new npm malware. Sigh.. This. But the problem seems to go way deeper than npm or whatever package manager is used. I mean, why is anyone consuming a package like colors or tinycolors? Do projects really need to drag in a random dependency to handle these usecases?

So rather than focusing on how Microsoft/npm et al can prevent similar situations in the future, you chose to think about what relevance/importance each individual package has? There will always be packages that for some people are "but why?" but for others are "thank god I don't have to deal with that myself". Sure, colors and whatnot are tiny packages we probably could do without, but what are you really suggesting…

> So rather than focusing on how Microsoft/npm et al can prevent similar situations in the future, (...)

There's some ignorance in your comment. If you read up on debug & chalk supply chain attack, you'll end up discovering that the attacker gained control of the account through plain old phishing. Through a 2FA reset email, to boot.

What exactly do you expect the likes of Microsoft to do if users hand over their access to third parties? Do you want to fix issues or to pile onto the usual targets?

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

#237

Post by Ajedi32 »

juliend2 wrote: post #195
cookiengineer wrote: post #112

Earlier quoted context omitted.

Part of the reason of my switch to using Go as my primary language is that there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x. These kind of projects usually are pretty great because they aim to work with CGO_ENABLED=0 so the libs are very portable and work with different syscall backends. Additionally I really like to go mod vendor my snapshot…

> there's this trend of purego implementations which usually aim towards zero dependencies besides the stdlib and golang.org/x. I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture. IMO, it might be due to the fact that Go mod came rather late in the game, while NPM was introduced near the beginning of NodeJS. But it might be more related to Go's target audience being mor…

> I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture.

I think it's because the final deliverable of Go projects is usually a single self-contained binary executable with no dependencies, whereas with Node the final deliverable is usually an NPM package which pulls its dependencies automatically.

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

#238

Post by rs999gti »

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

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

#239

Post by LaGrange »

zachrip wrote: post #119
lithos wrote: post #83

Earlier quoted context omitted.

Just more engineering leaning than you. Actual engineers have to analyze their supply chains, and so makes sense they would be baffled by NPM dependency trees that utterly normal projects grow into in the JavaScript ecosystem.

Do you think companies using node don't analyze supply chains? That's nonsense. Have you cargo installed a rust app recently? This isn't just a js issue. This needs to be solved across the industry and npm frankly has done a horrible job at it. We let people with billions of downloads a month with recently changed password/2fa publish packages? Why don't we pool assets as a collective to scan newly published packages…

> Do you think companies using node don't analyze supply chains?

I _know_ many don’t. In fact suggesting doing it is a good way to be looked at like a crazy person and be told something like “this is a yes place not a no place.”

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

#240

Post by pixl97 »

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.

I mean, what does do good if your supply chain is attacked?

This said, less potential vendors supplying packages 'may' reduce exposure, but doesn't remove it.

Either way, not running the bleeding edge packages unless it's a known security fix seems like a good idea.

Post reply on HN