Live data from Hacker News

NPM debug and chalk packages compromised

aikido.dev

461–470 of 796 posts

Re: NPM debug and chalk packages compromised

#461
post #273

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

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

ripgrep is quite well known. It’s not some obscure tool. Brew is a well-established package manager.

(I get that the same can be said for said for npm and the packages in question, but I don’t really see how the context of the thread matters in this case).

Re: NPM debug and chalk packages compromised

#462

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.

I blame the prevalence of package mangers in the first place. Never liked em, just for this reason. Things were fine before they became mainstream. Another annoying reason is package files that are set to grab the latest version, randomly breaking your environment. This isn't just npm of course, I hate them all equally.

I'm a little confused, is this rage bait or what?

> Things were fine before they became mainstream

As in, things were fine before we had commonplace tooling to fetch third party software?

> package files that are set to grab the latest version

The three primary Node.js package managers all create a lockfile by default.

Re: NPM debug and chalk packages compromised

#463
post #424

Earlier quoted context omitted.

APT repos for Debian, Trisquel, Ubuntu... require far more checkings and bureaucracy.

I'll bet they don't. There's way to much churn for it all to be checked

No, they are extremely well vetted. Have you ever heard of a supply chain attack involving Red Hat, Debian or Ubuntu repos?

Re: NPM debug and chalk packages compromised

#464
post #456

Earlier quoted context omitted.

AI based code review with escalation to a human

I'm curious :) Does the AI detect the obfuscation?

Probably. It’s trivial to plug some obfuscated code into an LLM and ask it what it does.

Re: NPM debug and chalk packages compromised

#465

Earlier quoted context omitted.

In terms of presentation, yes. In terms of substance, short deadlines are often what separate phishing from legitimate requests.

There is NO reliable indicators, because every single one of these "Legit requests don't ..." recommendations has been done by a local bank trying to get their customers to do something. My local credit union sent me a "please change your password" email from a completely unassociated email address with a link to the change password portal. I emailed them saying "Hey it looks like someone is phishing" and they said,…

> There is NO reliable indicators

Completely agree. The only reliable way is to never use an email/SMS link to login, ever.

Re: NPM debug and chalk packages compromised

#466

Earlier quoted context omitted.

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?

> don't we consider things like `brew` to be sufficiently low-risk, Like ... npm?

Nah…

Everybody knows npm is a gaping security issue waiting to happen. Repeatedly.

It’s convenient, so it’s popular.

Many people also don’t vendor their own dependencies, which would slow down the spread at the price of not being instantly up to date.

Re: NPM debug and chalk packages compromised

#467
post #97
post #43

Developer account got hijacked through phishing. @junon acknowledged this readily and is trying to get it sorted. Meanwhile, this is a mistake that can happen to anyone, especially under pressure. So no point in discussing the personal oversight. So let me raise a different concern. This looks like an exploit for web browsers, where an average user (and most above average users) have no clue as to what's running unde…

> Meanwhile, this is a mistake that can happen to anyone, especially under pressure. So no point in discussing the personal oversight. Unless this is a situation that could've been easily avoided with a password manager since the link was from a website not in your manager's database, so can't happen to anyone following security basics, and the point of discussing the oversight instead of just giving up is to increas…

I've mentioned this elsewhere. I was mobile, I don't often use it there, and I was in a rush.

Re: NPM debug and chalk packages compromised

#468

Earlier quoted context omitted.

Things like this are good illustrations as to why many feel that the entire JS ecosystem is broken. Even if you have a standard lib included in a language, you wouldn't expect a bigger binary because of the standard lib. The JS solution is often more duct tape on top of a bad design. In this case tree shaking, which may or may not work as intended.

I agree with you, but I'd ask- what other language needs to distribute to an unknown runtime environment over the network? If it's the browser's job to implement the standard library, how do you ensure that all browsers do this in a compliant and timely fashion? And if not, how do you optimise code-on-demand delivery over the internet? I don't deny there are/could be solutions to this. But historically JS devs have w…

> what other language needs to distribute to an unknown runtime environment over the network?

What is this unknown runtime environment? Even during the browser war, there was just an handful of browsers. And IE was the only major outlier. Checking the existence of features and polyfilling is not that complicated.

And most time, the browser is already downloading lot of images and other resources. Arguing about bundle size is very hypocritical of developers that won't blink at adding 17 analytics modules.

Re: NPM debug and chalk packages compromised

#469
post #246

Earlier quoted context omitted.

We also caught this right away at Socket, https://socket.dev/blog/npm-author-qix-compromised-in-major-... While it sucks that this happened, the good thing is that the ecosystem mobilized quickly. I think these sorts of incidents really show why package scanning is essential for securing open source package repositories.

[flagged]

You could at least offer some kind of substantive criticism of the tool (“socket”).
Post reply on HN