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

961–970 of 1001 posts

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

#961

Post by carols10cents »

CaptainOfCoit wrote: post #952
groby_b wrote: post #948

Earlier quoted context omitted.

> everything should be a library. That's exactly npm's problem, though. What everybody is avoiding to say is that you need a concept of "trusted vendors". And, for the "OSS accelerates me" business crowd, that means paying for the stuff you use. But who would want that when you're busy chasing "market fit".

> That's exactly npm's problem, though. I don't think that's the problem with npm. The problem with npm is that no packages are signed, at all, so it ends up trivial for hackers to push new package versions, which they obviously shouldn't be able to do.

Since Shai-Hulud scanned maintainers' computers, if the signing key was stored there too (without a password), couldn't the attackers have published signed packages?

That is, how does signing prevent publishing of malware, exactly?

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

#962

Post by pxc »

tarruda wrote: post #16
l___l wrote: post #10

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

Something similar to Deno's permission system, but operating at a package level instead of a process level. When declaring dependencies, you'd also declare the permissions of those dependencies. So a package like `tinycolor` would never need network or disk access.

Does Deno's sandboxing not extend to build time?

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

#963

Post by ozim »

wvh wrote: post #823
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…

As a security guy, for years, you get laughed out of the room suggesting devs limit their dependencies and don't download half of the internet while building. You are an obstruction for making profit. And obviously reading the code does very little since modern (and especially Javascript) code just glues together frameworks and libraries, and there's no way a single human being is going to read a couple million lines…

Package registries should step up. They are doing some stuff but still NPM could do more.

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

#964

Post by Hackbraten »

biggusdickus69 wrote: post #662
Hackbraten wrote: post #382

Earlier quoted context omitted.

How are users supposed to build and maintain a trust store? In a hypothetical scenario where npm supports signed packages, let's say the user is in the middle of installing the latest signed left-pad. Suddenly, npm prints a warning that says the identity used to sign the package is not in the user's local database of trusted identities. What exactly is the user supposed to do in response to this warning?

This is a solved problem. https://en.wikipedia.org/wiki/Web_of_trust

Imagine a hobbyist developer with a ~ $0 budget trying to publish their first package. How many thousands of km/miles are you expecting them to travel so they can get enough vouches for their package to be useful for even a single person?

Now imagine you're another developer who needs to install a specific NPM package published by someone overseas who has zero vouches by anyone in your web of trust. What exactly are you going to do?

In reality, forcing package publishers to sign packages would achieve absolutely nothing. 99.99 % of package consumers would not even bother to even begin building a web of trust, and just blindly trust any signature.

The remaining 0.01 % who actually try are either going to fail to gain any meaningful access to a WoT, or they're going to learn that most identities of package publishers are completely unreachable via any WoT whatsoever.

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

#965

Post by bigstrat2003 »

JoBrad wrote: post #905
Arcterus wrote: post #891

Earlier quoted context omitted.

> Standard libraries should include everything needed to interact with modern systems. This is great when the stdlib is well-designed and kept current when new standards and so on become available, but often "batteries included" approaches fail to cover all needs adequately, are slow to adopt new standards or introduce poorly designed modules that then cannot be easily changed, and/or fail to keep up-to-date with the…

The tradeoff of “batteries included” vs not is real: Python developers famously reach for community libraries like requests right away to avoid using the built-in tooling.

And yet, there are times where all I've had access to was the stdlib. I was damn glad for urllib2 at those times. It's worth it to have a batteries included stdlib, even if parts of it don't wind up being the most commonly used by the community.

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

#966

Post by ForHackernews »

Yasuraka wrote: post #939
ForHackernews wrote: post #821

Earlier quoted context omitted.

Git != Github. In practice, little difference between Go's use of Github and Python's use of PyPI. Someone at Microsoft with root access could compromise everyone.

> Git != Github That's why I'm putting emphasis on it, because to Go it is. And to languages that actually have centralized package repositories it isn't. There is a difference between code and packages and Go simply does not have the latter (in the traditional sense - what Go calls a package is a collection of source files in the same directory that are compiled together within a module (a module is a collection of…

I think you're being silly to be so insistent about this. 95% of Go packages are hosted on Github, a centralized hosting platform. The fact that they install via the git protocol (or do they? do they just use https to check out?) is immaterial.

95% of Python packages are installed from PyPI, but just like Go can also install from non-Github sources, Python supports installing from other non PyPI indexes[0] or even from a Git repository directly[1] like Go.

> what Go calls a package is a collection of source files in the same directory

What is it that you imagine Python or NPM packages consist of? Hint: A Python .whl file is just a folder in a zip archive (Python also supports source distributions directly analogous to Go)

[0] https://docs.astral.sh/uv/concepts/indexes/

[1] https://thelinuxcode.com/install-git-repository-branch-using...

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

#967

Post by lgas »

shakna wrote: post #666
bennyg wrote: post #642

Earlier quoted context omitted.

I didn't say generate :) - in all seriousness, I think you could reasonably have it copy the code for e.g. lodash.merge() and paste it into your codebase without the headaches you're describing. IMO, this method would be practical for a majority of npm deps in prod code. There are some I'd want to rely on the lib (and its maintenance over time), but also... a sort function is a sort function.

LLMs don't copy and paste. They ingest and generate. The output will always be a generated something.

You can give an LLM access to tools that it can invoke to actually copy and paste.

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

#968

Post by bigstrat2003 »

hoppp wrote: post #135
Xelbair wrote: post #32

Earlier quoted context omitted.

as much as i can yes. I try to avoid JS, as it is a horrible language, by design. That does include TS, but it at least is useable, but barely - because it still tied to JS itself.

Lucky you. I keep coming back to it because jobs and even for desktop apps a native webview beats everything else. We fcked up with js, big time and its with us forever now

A webview doesn't beat anything for desktop apps. It is the worst option available.

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

#969

Post by yawaramin »

bigstrat2003 wrote: post #965
JoBrad wrote: post #905

Earlier quoted context omitted.

The tradeoff of “batteries included” vs not is real: Python developers famously reach for community libraries like requests right away to avoid using the built-in tooling.

And yet, there are times where all I've had access to was the stdlib. I was damn glad for urllib2 at those times. It's worth it to have a batteries included stdlib, even if parts of it don't wind up being the most commonly used by the community.

The fact that there is a 'urllib2' implies that there's a 'urllib', which tells us something pretty important about the dangers of kitchen-sink standard libraries.

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

#970

Post by yawaramin »

carols10cents wrote: post #961
CaptainOfCoit wrote: post #952

Earlier quoted context omitted.

> That's exactly npm's problem, though. I don't think that's the problem with npm. The problem with npm is that no packages are signed, at all, so it ends up trivial for hackers to push new package versions, which they obviously shouldn't be able to do.

Since Shai-Hulud scanned maintainers' computers, if the signing key was stored there too (without a password), couldn't the attackers have published signed packages? That is, how does signing prevent publishing of malware, exactly?

How did Shai-Hulud get access to maintainers' computers?
Post reply on HN