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

561–570 of 796 posts

Re: NPM debug and chalk packages compromised

#561

Post by DimmieMan »

tracker1 wrote: post #521
SahAssar wrote: post #484

Earlier quoted context omitted.

It's not, and a third of them are tagged as unstable. JSR also still seems to not encourage proper versioning.

They are published as separate packages, but managed in the same repo by the Deno team. Versioning works fine with JSR. A fully-formed standard library doesn't spring into existence in a day.

They seem pretty cautious with that unstable flag too.

UUID v7 for example is unstable and one would be pretty confident in that not changing at this stage.

Many unstable functions have less churn than a lot of other “stable” packages. It’s a standard library so it’s the right place to measure twice before cementing it forever.

Re: NPM debug and chalk packages compromised

#562

Post by josephg »

hsbauauvhabzb wrote: post #497
fn-mote wrote: post #469

Earlier quoted context omitted.

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

Do I need any? Automated tools cannot prevent malicious code being injected. While they can make attempts to evaluate common heuristics and will catch low hanging malware, they are not fool proof against highly targeted attacks. Either way, the parent post is clearly ambulance chasing rather than having a productive conversation, which should really be about whether or not automatically downloading and executing huge…

> Do I need any? Automated tools cannot prevent malicious code being injected. While they can make attempts to evaluate common heuristics and will catch low hanging malware, they are not fool proof against highly targeted attacks.

So just because a lock isn't 100% effective at keeping out criminals we shouldn't lock our doors?

Re: NPM debug and chalk packages compromised

#563

Post by jmb99 »

ATechGuy wrote: post #555
33a wrote: post #498

Earlier quoted context omitted.

We use a mix of static analysis and AI. Flagged packages are escalated to a human review team. If we catch a malicious package, we notify our users, block installation and report them to the upstream package registries. Suspected malicious packages that have not yet been reviewed by a human are blocked for our users, but we don't try to get them removed until after they have been triaged by a human. In this incident,…

You rely on LLMs riddled with hallucinations for malware detection?

I'm not exactly pro-AI, but even I can see that their system clearly works well in this case. If you tune the model to favour false positives, with a human review step (that's quick), I can image your response time being cut from days to hours (and your customers getting their updates that much faster).

Re: NPM debug and chalk packages compromised

#564

Post by jmb99 »

Yoric wrote: post #415
junon wrote: post #349

Earlier quoted context omitted.

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

Wouldn't they have been able to change your key if they had compromised your entire npm account? Also, junon.support++ – big thanks for being clear about all this.

Push to many repos with a brand new key would (should) trigger red flags.

Re: NPM debug and chalk packages compromised

#565

Post by typpilol »

crabmusket wrote: post #535
skydhash wrote: post #468

Earlier quoted context omitted.

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

> Checking the existence of features and polyfilling is not that complicated. Judging by what we see in the world, most developers don't agree with you. And neither do I. A handful of browsers, multiplied by many versions per browser in the wild (before evergreen browsers like Chrome became widespread, but even today with e.g. Safari, or enterprise users), multiplied by a sprawling API surface (dare I say it, a stand…

Explain browser defaults to non JavaScript people is kind of eye opening I've found

Re: NPM debug and chalk packages compromised

#566

Post by anonymars »

metafunctor wrote: post #384
0cf8612b2e1e wrote: post #299

Earlier quoted context omitted.

Not a web guy, but that seems a bonkers default. I would have naively assumed a lockfile would be used unless explicitly ignored.

Welcome to the web side. Everything’s bonkers. Hard-earned software engineering truths get tossed out, because hey, wtf, I’ll just do some stuff and yippee. Feels like everyone’s stuck at year three of software engineering, and every three years the people get swapped out.

The web saw "worse is better" and said "hold my beer"

Re: NPM debug and chalk packages compromised

#567

Post by josephg »

junon wrote: post #349
Cthulhu_ wrote: post #333

Earlier quoted context omitted.

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.

Yeah; I wish provenance was more widely used. I think about this a lot for mobile apps. If you take an opensource iOS app like signal, you can read the source code on github. But there's actually no guarantee that the code on github corresponds in any way to the app I download from the app store.

With nodejs packages, I can open up node_modules and read the code. But packages get a chance to run arbitrary code on your computer after installation. By the time you can read the source code, it may be too late.

Re: NPM debug and chalk packages compromised

#568

Post by SchemaLoad »

rtpg wrote: post #504
const_cast wrote: post #490

Earlier quoted context omitted.

A lot of these security measures have trade offs, particularly when we start looking at heuristics or attestation-like controls. These can exclude a lot of common systems and software, including automations. If your heuristic is quite naive like "is using Linux" or "is using Firefox" or "has an IP not in the US" you run into huge issues. These sound stupid, because they are, but they're actually pretty common across…

I have a hard time arguing that 2FA isn't a massive win in almost every circumstance. Having a "confirm that you have uploaded a new package" thing as the default seems good! Someone like npm mandating that a human being presses a button with a recaptcha for any package downloaded by more than X times per week just feels almost mandatory at this point. The attacks are still possible, but they're not going to be nearl…

2FA is a huge benefit over plain passwords. But it wasn't enough here. The package dev had 2FA and it did not help since they got tricked in to logging in to a phishing page which proxied the 2FA code to the real login page.

Re: NPM debug and chalk packages compromised

#569

Post by giveita »

ropable wrote: post #554
0xbadcafebee wrote: post #278

Here we are again. 12 days ago ( https://news.ycombinator.com/item?id=45039764 ) I commented how a similar compromise of Nx was totally preventable. Again, this is not the failure of a single person. This is a failure of the software industry . Supply chain attacks have gigantic impacts. Yet these are all solved problems. Somebody has to just implement the standard security measures that prevents these compromises. W…

> Somebody has to just implement the standard security measures that prevents these compromises. I don't disagree, but this sentence is doing a lot of heavy lifting. See also "draw the rest of the owl".

Part of the owl can be how consumers upgrade. Don't get the latest patches but keep things up to date. Secondary sources of information about good versions to upgrade to and when. Allows time for vulns to be discovered like this before upgrading. Assumption is people can detect vulns before mass of people installing, which I think is true. Then you just need exceptions for critical security fixes.

Re: NPM debug and chalk packages compromised

#570

Post by sidcool »

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…

Thanks for your response. But this does call for preventing a single point of failure for security.
Post reply on HN