Live data from Hacker News

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

socket.dev

571–580 of 1001 posts

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

#571
post #564
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…

Maybe one approach would be to pin all dependencies, and not use any new version of a package until it reaches a certain age. That would hopefully be enough time for any issues to be discovered?

People living on the latest packages with their dependabots never made any sense to me, ADR. They trusted their system too much

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

#572
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…

Stick to (pin) old stable versions, don't upgrade often. Pain in the butt to deal with eventual minimum-version-dependency limitations, but you don't get the brand new releases with bugs. Once a year, get all the newest versions and figure out all the weird backwards-incompatible bugs they've introduced. Do it over the holiday season when nobody's getting anything done anyway.

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

#573
post #513

Earlier quoted context omitted.

Your typical Rust project does not have over 1000 dependencies. Zed is not a typical Rust project; it's a full fledged editor that includes a significant array of features and its own homegrown UI framework .

What is a "typical Rust project", I wonder?

One famous example is ripgrep (https://github.com/BurntSushi/ripgrep). Its Cargo.lock (which contains all direct and indirect dependencies) lists 65 dependencies (it has 66 entries, but one of them is for itself).

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

#574
post #553

Earlier quoted context omitted.

Install less dependencies, code more.

Sure, and I do that whenever I can. But I'm not going to write my own react, or even my own react-hook-form. I'm not going to rewrite stripe-js. Looking through my 16 direct dependencies -- that pull in a total of 653 packages, jesus christ -- there's only one of them that I'd consider writing myself (js-cookie) in order to reduce my dependency count. The rest would be a maintenance burden that I shouldn't have to ta…

There's this defense mechanism that I don't know how it's called, but when someone takes a criticism to the extreme to complain about it being unfeasible.

Criticism: "You should shower every day"

Defense: "OH, maybe I should shower every hour, to the point where my skin dries and I can't get my work done because I'm in the shower all day."

No, there's a pretty standard way of doing things that you can care to learn, and it's very feasible, people shower every day during the week, sometimes they skip if they don't go out during weekends, if it's very cold you can skip a day, and if it's hot you can even shower twice. You don't even need to wash your hair every day. There's nuance that you can learn if you stop being so defeatist about it.

Similarly, you can of course install stripe-js since it's vendored from a paid provider with no incentive to fuck you with malware and with resources to audit dependency code, at any rate they are already a dependency of yours, so adding an npm package does not add a vendor to your risk profile.

Similarly you can add react-hook-form if it's an official react package, however if it isn't, then it's a risk, investigate who uploads it, if it's a random from github with an anime girl or furry image in their profile, maybe not. Especially if the package is something like an unofficial react-mcp-dotenv thing where it has access to critical secrets.

Another fallacy is that you have to rewrite the whole dependency you would otherwise import. False. You are not going to write a generic solution for all use cases, just for your own, and it will be tightly integrated and of higher quality and less space (which helps with bandwidth, memory and CPU caching), because of it. For god's sake, you used an example relating to forms? We've had forms since the dot com boom, how come you are still having trouble with those? You should know them like the back of your hand.

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

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

I suppose it's only a matter of time before one of these supply chain attacks unintentionally pulls in a second, unrelated supply chain attack.

fish grow to the meet the size of the fishbowl

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

#576
post #541

Earlier quoted context omitted.

Copy-paste more.

I guess this is a joke, but imo it shouldn't be.

I'm all for disregarding DRY and copypasting code you wrote.

But I think for untrusted third party code, it's much better to copy the code by hand, that way you are really forced to audit it. There really isn't much of an advantage to copying an install.sh script compared to just downloading a running the .sh, whereas writing the actual .sh commands on the command line (and following any other URLs before executing them) is golden.

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

#577
post #476
post #280

Earlier quoted context omitted.

> I'm interested in knowing whether there's something intrinsic to Go that encourages such a culture. I've also seen something similar with Java, with its culture of "pure Java" code which reimplements everything in Java instead of calling into preexisting native libraries. What's common between Java and Go is that they don't play well with native code; they really want to have full control of the process, which is m…

I think it's important for managed/safe languages to have their own implementations of things, and avoid dropping down into C/C++ code unless absolutely necessary. ~13 years ago I needed to do DTLS (TLS-over-UDP) from a Java backend, something that would be exposed to the public internet. There were exactly zero Java DTLS implementations at the time, so I chose to write JNI bindings to OpenSSL. I was very unhappy wit…

> or 2) write my own DTLS implementation in Java, and virtually guarantee I'd get something wrong and break it cryptographically.

Java doesn't have constant time guarantees, so for at least the cryptographic part you have to call to a non-Java library, ideally one which implements the cryptographic primitives in assembly (unfortunately, even C doesn't have constant time guarantees, though you can get close by using vector intrinsics).

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

#578
post #564
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…

Maybe one approach would be to pin all dependencies, and not use any new version of a package until it reaches a certain age. That would hopefully be enough time for any issues to be discovered?

Packages can still be updated, even if pinned. If a dependency of a dependency is not pinned - it can still be updated.

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

#579
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…

>> and keeping them to well-known and trustworthy (security-wise) creators.

The true threat here isn't the immediate dependency though, it's the recursive supply chain of dependencies. "trustworthy" doesn't make any sese either when the root cause is almost always someone trustworthy getting phished. Finally if I'm not capable of auditing the dependencies it's unlikely I can replace them with my own code. That's like telling a vibe coder the solution to their brittle creations is to not use AI and write the code themselves.

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

#580

Earlier quoted context omitted.

Almost all software has a no warranty clause. I am not a lawyer but in pretty plain English every piece of software I have ever used has said exactly that I can fuck off if I expect it to work or do anything. To clarify - I dont think it is naive to assume the software is as-is with all responsibilities on the user since that is exactly what lawyers have made all software companies say that for over 50 years.

I'm not sure what your point is. I was saying it's naive to think that everyone is going to review all dependencies, and we can do better than requiring them to.

I thought my point was clearly made the 1st time.

How can we promise to "do better" when shit like "no author or distributor accepts responsibility to anyone for the consequences of using it or for whether it serves any particular purpose or works at all" is in the legal agreement of the software you are using?

Making someone agree to that while simultaneously on the side making promises that the software works is used car salesman gimmicks. The only things that matters is what you put in writing.

Post reply on HN