Live data from Hacker News

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

socket.dev

651–660 of 1001 posts

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

#651
post #505

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

> 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 I do not know about NPM. But in Rust this is common practice. Very hard to avoid. The core of Rust is very thin, to get anything done typically involves dozens of crates, all pulled in at compile time from any old developer impli…

The same is true for go and for java.

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

#652

Earlier quoted context omitted.

Don't update your dependencies manually. Setup renovate to do it for you, with a delay of at least a couple of weeks, and enable vulnerability alerts so that it opens PRs for publicly known vulnerabilities without delay https://docs.renovatebot.com/configuration-options/#minimumr... https://docs.renovatebot.com/presets-default/#enablevulnerab...

Why was this comment downvoted? Please explain why you disagree.

I didn’t downvote, but...

Depending on a commercial service is out of the question for most open source projects.

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

#653
I have been telling people for ages - Javascript is a pack of cards. We have progressed as a society and have so many alternatives for everything, and yet, we still haven't done anything about Javascript being forced down onto us by browsers. If it wasn't for web browsers, JS would have become irrelevant so fast because of how broken it is - both as a language and its ecosystem.

On the contrary - almost being a decade into Elixir - most of the time, I don't need (and I don't like) using external dependencies. I can just write something myself in a matter of just an hour or so because it's just so easy to do it myself. And everything I've written till date hasn't required an audit or re-write every 6 months or sometimes, even for years.

We all seem to hate the concept of Nazis and yet somehow we have done nothing about the Nazi-est language of them all which literally has no other alternatives to run on web browsers?

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

#654

My comment yesterday, which received one downvote and which I will repeat if/until they’re gone: HTTP and JS have to go. There are ways to replace them.

HTTP?

We have good protocols for sharing programs. HTTP was designed to share stylized documents which it’s OK at. The browser probably should have stuck to rendering and left the p2p file sharing to a better protocol. It absolutely is not fit for the problem domain its been shoehorned into nor does it need to serve that role.

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

#655
post #653

I have been telling people for ages - Javascript is a pack of cards. We have progressed as a society and have so many alternatives for everything, and yet, we still haven't done anything about Javascript being forced down onto us by browsers. If it wasn't for web browsers, JS would have become irrelevant so fast because of how broken it is - both as a language and its ecosystem. On the contrary - almost being a decad…

[deleted]

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

#656
post #649
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…

I recently started using npm for an application where there’s no decent alternative ecosystem. The signal desktop app is an electron app. Presumably it has the same problem. Does anyone know of any reasonable approaches to using npm securely? “Reduce your transitive dependencies” is not a reasonable suggestion. It’s similar to “rewrite all the Linux kernel modules you need from scratch” or “go write a web browser”.

Most big tech companies maintain their own NPM registry that only includes approved packages. If you need a new package available in that registry you have to request it. A security team will then review that package and its deps and add it to the list of approved packages…

I would love to have something like that "in the open"…

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

#657

Earlier quoted context omitted.

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.

The perfect storm of on the one side junior developers who are afraid of writing even trivial code and are glad if there's a package implementing functionality that can be done in a one-liner, and on the other side (often junior) developers who want to prove themselves and think the best way to do that is to publish a successful npm package

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

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

I like to pin specific versions in my package.json so dependencies don't change without manual steps, and use "npm ci" to install specifically the versions in package-lock.json. My CI runs "npm audit" which will raise the alarms if a vulnerability emerges in those packages. With everything essentially frozen there either is malware within it, or there is not going to be, and the age of the packages softly implies there is not.

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

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

The article explicitly mentions a way to do this:

Use NPM Package Cooldown Check

The NPM Cooldown check automatically fails a pull request if it introduces an npm package version that was released within the organization’s configured cooldown period (default: 2 days). Once the cooldown period has passed, the check will clear automatically with no action required. The rationale is simple - most supply chain attacks are detected within the first 24 hours of a malicious package release, and the projects that get compromised are often the ones that rushed to adopt the version immediately. By introducing a short waiting period before allowing new dependencies, teams can reduce their exposure to fresh attacks while still keeping their dependencies up to date.

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

#660

So, other packaging environments have a tendency to slow down the rate of change that enters the user's system. Partly through the labor of re-packaging other people's software, but also as a deliberate effort. For instance: Ubuntu or RedHat. Is anyone doing this in a "security as a service" fashion for JavaScript packages? I imagine a kind of package escrow/repository that only serves known secure packages, and acti…

I've worked in companies that do this internally, e.g., managed pull-through caches implemented via tools like Artifactory, or home-grown "trusted supply chain" automation, i.e., policy enforcement during CI/CD prior to actually consuming a third-party dependency. But what you describe is an interesting idea I hadn't encountered before! I assume such a thing would have lower adoption within a relatively fast-moving e…

How does a pull-through cache prevent this issue? Wouldn’t it also just pull the infected version from the upstream registry?
Post reply on HN