Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

Post reply on HN
Print view View original

341–350 of 796 posts

Re: NPM debug and chalk packages compromised

#341

Post by bnchrch »

PokestarFan wrote: post #174
cddotdotslash wrote: post #154

NPM deserves some blame here, IMO. Countless third party intel feeds and security startups can apparently detect this malicious activity, yet NPM, the single source of truth for these packages, with access to literally every data event and security signal, can't seem to stop falling victim to this type of attack? It's practically willful ignorance at this point.

NPM is owned by GitHub and therefore Microsoft, who is too busy putting in Copilot into apps that have 0 reason to have any form of generative AI in them

Good god. Not everything has to be about your opinion on AI.

Re: NPM debug and chalk packages compromised

#342

Post by tripplyons »

koolba wrote: post #187
joaomoreno wrote: post #129

From sindresorhus: You can run the following to check if you have the malware in your dependency tree: `rg -u --max-columns=80 _0x112fa8` Requires ripgrep: `brew install rg` https://github.com/chalk/chalk/issues/656#issuecomment-32668...

Try the same recursive grep on ~/.npm to see if you have it cached too. Not just the latest in the current project.

Haven't installed any modules today, but I ran these commands to clear caches for npm and pnpm just to be safe.

npm cache clean --force pnpm cache delete

Re: NPM debug and chalk packages compromised

#343

Post by behindsight »

alaintno wrote: post #2

How is it possible that this code (line 9 of the index.js) isn't present in the source github repo, but can be seen in the beta feature of npmjs.com? Also, the package 1.3.3 has been downloaded 0 times according to npmjs.com, how can the writer of this article has been able to detect this and not increment the download counter?

> How is it possible that this code (line 9 of the index.js) isn't present in the source github repo, but can be seen in the beta feature of npmjs.com

You may also be interested in npm package provenance [1] which lets you sign your npm published builds to prove it is built directly from the source being displayed.

This is something ALL projects should strive to setup, especially if they have a lot of dependent projects.

1: https://github.blog/security/supply-chain-security/introduci...

Re: NPM debug and chalk packages compromised

#344

Post by tripplyons »

hunter2_ wrote: post #326
yifanl wrote: post #273

Earlier quoted context omitted.

Asking people to run random install scripts just feels very out of place given the context.

I would agree if this were one of those `curl | sh` scenarios, but don't we consider things like `brew` to be sufficiently low-risk, akin to `apt`, `dnf`, and the like?

Anyone can upload an NPM package without much review. For Homebrew, you at least have to submit a pull request.

Re: NPM debug and chalk packages compromised

#346

Post by mrguyorama »

rudedogg wrote: post #41
thewebguyd wrote: post #32

Earlier quoted context omitted.

Lack of a good batteries-included stdlib. You're either importing a ton of little dependencies (which then depend on other small libraries) or you end up writing a ton of really basic functionality yourself.

This is the answer IMO. The number of targets and noise would be a lot less if JS had a decent stdlib or if we had access to a better language in the browser. I have no hope of this ever happening and am abandoning the web as a platform for interactive applications in my own projects. I’d rather build native applications using SDL3 or anything else.

But this can't be the whole story. In the Java world, it's pretty common to import a couple huge libraries full of utility functions, but those are each one import, that you can track and version and pay attention to.

Apache Commons helper libraries don't import sub libraries for every little thing, they collect a large toolbox into a single library/jar.

Why instead do people in the javascript ecosystem insist on separating every function into it's own library that STILL has to import helper libraries? Why do they insist on making imports fractally complex for zero gain?

Re: NPM debug and chalk packages compromised

#348

Post by SAI_Peregrinus »

grishka wrote: post #40
rglover wrote: post #28

Earlier quoted context omitted.

You typically don't. But a lot of packages that you do install depend on smaller stuff like this under the hood (not necessarily good and obviously better handled with bespoke code in the package, but is is what it is).

Then the question becomes, why do developers of larger libraries import someone else's module for every little trivial thing?

Sometimes it's not someone else's module, it's their own. They break up the big library into reusable components, and publish them all separately. Essentially taking DRY to an extreme: don't have private functions, make all your implementation details part of the public API & reuse them across projects.

Re: NPM debug and chalk packages compromised

#349

Post by junon »

Cthulhu_ wrote: post #333
junon wrote: post #9

Hi, yep I got pwned. Sorry everyone, very embarrassing. More info: - https://github.com/chalk/chalk/issues/656 - https://github.com/debug-js/debug/issues/1005#issuecomment-3... Affected packages (at least the ones I know of): - ansi-styles@6.2.2 - debug@4.4.2 (appears to have been yanked as of 8 Sep 18:09 CEST) - chalk@5.6.1 - supports-color@10.2.1 - strip-ansi@7.1.1 - ansi-regex@6.2.1 - wrap-ansi@9.0.1 - color-conve…

Tbh, it's not your fault per se; everybody can fall for phishing emails. The issue, IMO, lies with npmjs which publishes to everyone all at the same time. A delayed publish that allows parties like Aikido and co to scan for suspicious package uploads first (e.g. big changes in patch releases, obfuscated code, code that intercepts HTTP calls, etc), and a direct flagging system at NPM and / or Github would already be a…

Being able to sign releases would help, too. I would happily have that enabled since I'm always publishing from one place.

Re: NPM debug and chalk packages compromised

#350

Post by billywhizz »

aabbccsmith wrote: post #211
simpaticoder wrote: post #121

I've come to the conclusion that avoiding the npm registry is a great benefit. The alternative is to import packages directly from the (git) repository. Apart from being a major vector for supply-chain attacks like this one, it is also true that there is little or no coupling between the source of a project and its published code. The 'npm publish' step takes pushes local contents into the registry, meaning that a ma…

npm's recent provenance feature fixes this, and it's pretty easy to setup. It will seriously help prevent things like this from ever happening again, and I'm really glad that big packages are starting to use it.

> When a package in the npm registry has established provenance, it does not guarantee the package has no malicious code. Instead, npm provenance provides a verifiable link to the package's source code and build instructions, which developers can then audit and determine whether to trust it or not
Post reply on HN