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

981–990 of 1001 posts

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

#981

Post by lelanthran »

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?

In past comments I said that a quick win would be to lean on certificates; those can't easily be forged once a certificate is accepted.

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

#982

Post by Maskawanian »

paulddraper wrote: post #385
Maskawanian wrote: post #348

Earlier quoted context omitted.

Golang at least gives you the option to easily vendor-ize packages to your local repository. Given what has happened here, maybe we should start doing this more!

npm has always downloaded to the current directory.

That isn't the same as vendor-izing unless you are committing node_modules to your VCS, which would be insane.

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

#983

Post by kjok »

singulasar wrote: post #846
kjok wrote: post #332

Earlier quoted context omitted.

Why should MS buy any of these startups when a developer (not any automated tech) found the malware? It looks like these startups did after-the-fact analysis for PR.

on the other hand, the previous supply chain attack was found by automated tech. Also, if MS would be so kind as to just run similar scans at the time a package is updated instead of after the package is updated (which is the only way the automated tech can run if npm doesn't integrate it), then malware like this would be way less common. MS doesn't care

> on the other hand, the previous supply chain attack was found by automated tech.

Are you sure about this? Would love to see which ones.

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

#984

Post by 0x000xca0xfe »

Onavo wrote: post #959
0x000xca0xfe wrote: post #811

Earlier quoted context omitted.

It's trivial to run an exploit shell from almost any language when you have non-sandboxed code running on the target machine.

Yes but outside of dumping user data, there's not much else you can do. Crypto mining will get caught rather quickly (most big clouds ban mining). User data is useful for the type of attacker that's willing to go through the whole blackmarketing selling process. For script kiddies, if you think about it, the easiest pay-off for a social engineering/phishing is a frontend wallet crypto theft.

This has still nothing to do with the language or kernel exploits. Only code execution on a valuable host matters.

You could make a malicious Rust crate that on installation runs a Python shell and injects JavaScript into your browser to extract crypto wallets. There even seems to be a significant overlap of Rust devs/crypto fans.

Also script kiddies don't do social engineering and blackmarket crypto selling, that's 100% professional crime territory. Real-life script kiddie attacks I've seen were more like hacking an ecommerce site and adding bananas as currency.

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

#985

Post by singulasar »

kjok wrote: post #983
singulasar wrote: post #846

Earlier quoted context omitted.

on the other hand, the previous supply chain attack was found by automated tech. Also, if MS would be so kind as to just run similar scans at the time a package is updated instead of after the package is updated (which is the only way the automated tech can run if npm doesn't integrate it), then malware like this would be way less common. MS doesn't care

> on the other hand, the previous supply chain attack was found by automated tech. Are you sure about this? Would love to see which ones.

The chalk/debug one https://www.aikido.dev/blog/npm-debug-and-chalk-packages-com... I believe socket also found it this way just a bit later.

The dev later said that Charlie notifying him probably shaved off some very important time for the remediation.

So in this case 2 different companies found it using automated tech before anyone else

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

#986

Post by goku12 »

qcnguy wrote: post #978
goku12 wrote: post #899

Earlier quoted context omitted.

> This is the right answer. I'm willing to stick my head out and assert that languages with a "minimal" standard library are defective by design. > Standard libraries should include everything needed to interact with modern systems. This means HTTP parsing, HTTP requests, and JSON parsing. There is another way. Why not make the standard library itself pluggable? Rust has a standard library and a core library. The sta…

This is the philosophy used by the Java world. Big parts of the standard library are plugin-based. For example, database access (JDBC), filesystem access (NIO), cryptography (JCA). The standard library defines the interfaces and sometimes provides a default implementation, but it can be extended or replaced. It works well, but the downside of that approach is people complaining about how abstract things are.

That makes sense. Just adding a clarification here. I wasn't suggesting to replace the standard library with interfaces (traits in this case). I was saying that the core library/runtime should have the interfaces for the standard library to implement some bare minimum functionalities like the allocators. Their use is more or less transparent to the application and 3rd party library developers.

Meanwhile, the public API of the selected standard library need not be abstract at all. Let's say that the bare minimum functionality expected from a 3rd party standard library is the same as the official standard library. They can just reimplement the official standard library at the minimum.

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

#987

Post by amai »

pier25 wrote: post #912
amai wrote: post #864

NPM belongs to Microsoft. What kind of security do you expect?

You're saying this as if big corps, banks, etc weren't using dotnet.

They should not. Microsoft lost the master key to the Azure cloud in 2023. Just now they have this issue: https://www.wired.com/story/microsoft-entra-id-vulnerability...

MS stands for minimal security.

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

#988

Post by cutemonster »

zelphirkalt wrote: post #848
jand wrote: post #817

Earlier quoted context omitted.

Who do you mean with "many people"? Developers who do not care or middle management that oversold features and overcommitted w.r.t. deadlines? Or both? Someone else?

I was thinking of many developers, but actually middle management should be included.

And the CEO. And lawmakers

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

#989

Post by int_19h »

Ajedi32 wrote: post #293
int_19h wrote: post #284

Earlier quoted context omitted.

With Node the final deliverable is an app that comes packaged with all its dependencies, and often bundled into a single .js file, which is conceptually the same as a single binary produced by Go.

Can you give an example? While theoretically possible I almost never see that in Node projects. It's not even very practical because even if you do cram everything into a single .js file you still need an external dependency on the Node runtime.

Examples would be most Node server web apps. It is standard practice to run a bundler for prod deployments.

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

#990

Post by lmz »

smaudet wrote: post #752
lmz wrote: post #747

Earlier quoted context omitted.

It's not the language it's the library that's not designed to isolate untrusted code from the start. Much harder to exit the sandbox if your only I/O mechanism is the DOM, alert() and prompt().

And the whole rest of the Internet... The issue here is not Java or it's complexity. The point is also not Java, it's incidental that it was popular at the time. It's people acting irrationally about things and jumping ship for an even-worse system. Like, yes, if that really were the whole attack surface of JS, sure nobody would care. They also wouldn't use it...and nothing we cared about would use it either...

The security issues with Java applets usually led to local unsandboxed code execution. It's a lot harder to do that with JS because just running Java and confusing the security manager gets you full Java library access, vs JS with no built in I/O.
Post reply on HN