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

471–480 of 1001 posts

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

#471

Post by jen20 »

zwnow wrote: post #404
ncruces wrote: post #381

Earlier quoted context omitted.

This is a culture issue with developers who find it OK to have hundreds of (transitive) dependencies, and then follow processes that, for all intents and purposes, blindly auto update them, thereby giving hundreds of third-parties access to their build (or worse) execution environments. Adding friction to the sharing of code doesn't absolve developers from their decision to blindly trust a ridiculous amount of third-…

Unfortunately that's almost the whole industry. Every software project I've seen has an uncountable amount of dependencies. No matter if npm, cargo, go packages, whatever you name.

Zero-external-dependency Go apps are far more feasible than Rust or Node, simply because of the size and quality of the standard library.

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

#472

Post by naasking »

This is a product of programming languages continuing to ignore the lessons from capability security. The fact that packages in your programming language even have the ability to any of the things listed in these articles by default is an embarrassing, abject failure of our profession.

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

#473

Post by zelphirkalt »

brianleb wrote: post #438
lukan wrote: post #431

Earlier quoted context omitted.

"rewrite every single dependency from scratch" No need to. But also no need to pull in a dependency that could be just a few lines of own (LLM generated) code.

>>a few lines of own (LLM generated) code. ... and now you've switched the attack vector to a hostile LLM.

Though you will see the code at least, when you are copy pasting it and if it is really only a few lines, you may be able to review it. Should review it of course.

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

#474

Post by hermannj314 »

IshKebab wrote: post #454
eschneider wrote: post #449

Earlier quoted context omitted.

If you pull something into your project, you're responsible for it working. Full stop. There are a lot of ways to manage/control dependencies. Pick something that works best for you, but be aware, due diligence, like maintenance is ultimately your responsibility.

That's very naive. We can do better than this.

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.

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

#475

Post by zelphirkalt »

2muchcoffeeman wrote: post #462
gameman144 wrote: post #416

Earlier quoted context omitted.

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

Have we all forgotten the left-pad incident? This is an eco system that has taken code reuse to the (unreasonable) extreme. When JS was becoming popular, I’m pretty sure every dev cocked an eyebrow at the dependency system and wondered how it’d be attacked.

> This is an eco system that has taken code reuse to the (unreasonable) extreme.

Not even that actually. Actually the wheel is reinvented over and over again in this exact ecosystem. Many packages are low quality, and not even suitable to be reused much.

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

#476

Post by kelnos »

cesarb wrote: post #280
juliend2 wrote: post #195

Earlier quoted context omitted.

> 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'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 with this: my choices were to 1) accept that my service could now segfault -- possibly in an exploitable way -- if there was a bug in my bindings or in OpenSSL's (not super well tested) DTLS code, or 2) write my own DTLS implementation in Java, and virtually guarantee I'd get something wrong and break it cryptographically.

These were not great choices, and I wished I had a Java DTLS implementation to use.

This is why in my Rust projects, I generally prefer to tell my dependencies to use rustls over native (usually OpenSSL) TLS when there's an option between the two. All the safety guarantees of my chosen language just disappear whenever I have to call out to a C library. Sure, now I have to worry about rustls having bugs (as a much less mature implementation), but at least in this case there are people working on it who actually know things about cryptography and security that I don't, and they've had third-party audits that give me more confidence.

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

#477

Post by Yeroc »

lucideer wrote: post #402
Yeroc wrote: post #324

Earlier quoted context omitted.

> Maven land is full of plugins with automated pom.xml version templating that has effectively the same effect as lax versioning, but without any strict adherence to any kind of standard like semver. Please elaborate on this. I'm a long-time Java developer and have never once seen something akin to what you're describing here. Maven has support for version ranges but in practice it's very rarely used. I can expect a…

I'm not a Java (nor Kotlin) developer - I've only done a little Java project maintenance & even less Kotlin - I've mainly come at this as a tooling developer for dependency management & vulnerability remediation. But I have seen a LOT of varied maven-managed repos in that line of work (100s) and the approaches are wide - varied. I know this is possible with custom plugins but I've mainly just seen it using maven wrap…

There are things that are potentially possible such as templating pom.xml build files or adjusting dependencies based on user properties (this that what you're suggesting?), but what you're describing is definitely not normal, or best practice in the ecosystem and shouldn't be presented as if it's normal practice.

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

#478

Post by btown »

noodlesUK wrote: post #299
btown wrote: post #252

Earlier quoted context omitted.

I'd like to think there are ways to do this and keep things decentralized. Things like: Once a package has more than [threshold] daily downloads for an extended period of time, it requires 2FA re-auth/step-up on two separate human-controlled accounts to approve any further code updates. Or something like: for these popular packages, only a select list of automated build systems with reproducible builds can push direc…

I think that we should impose webauthn 2fa on all npm accounts as the only acceptable auth method if you have e.g., more than 1 million total downloads. Someone could pony up the cash to send out a few thousand yubikeys for this and we'd all be a lot safer.

Even the simplest "any maintainer can click a push notification on their phone to verify that they want to push an update to $package" would have stopped this worm in its tracks!

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

#480

Post by Melatonic »

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…

Lot of software has update policies like this and then also people will run a separate test environment updating to latest
Post reply on HN