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

Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

safedep.io

Post reply on HN
Print view View original

231–240 of 329 posts

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#231

Post by WorldMaker »

tln wrote: post #211
WorldMaker wrote: post #192

Earlier quoted context omitted.

> Do any language standard libraries have a "3 hours ago" formatter? Thats what timeago.js does There's also a platform feature for that now: Intl.RelativeTimeFormat: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... It asks you to do the basic time math to determine your granularity so there's still a role for a library, but also that time math gets easier with Temporal: https://developer.mozilla.org/e…

Thanks for that! So, back to the GP post - TC39 should make a bigger stdlib. Lets say timeago.js is warranted (as a polyfill and terser API) AND TC39 is taking action. On slice.js, TC39 took action AND usage is unwarranted since the functionality is widely available. Maybe a stride.js would be needed. There are 2 modules where npm's culture of "tiny modules because the stdlib is impoverished" holds - but the issue is…

> Lets say timeago.js is warranted (as a polyfill and terser API)

Though it may be useful to point out that timeago.js specifically is not a wrapper for Intl.RelativeTimeFormat. It implements its own unique internationalization beyond/instead of the platform capability. (Similarly, so do Moment, Luxon, and date-fns.)

I would argue that it is unwarranted to use such libraries, because we can do better in Vanilla with platform features now. Though yes, Safari still doesn't implement enough of Temporal today for it to be considered Baseline Widely Available. (There also are direct Temporal polyfills. Surprisingly I've found vanilla polyfilling with Date by hand isn't terrible enough to warrant a Temporal polyfill, but also my most complex Temporal math is usually server-side in Deno.)

But yeah, that's mostly quibbling outside of the point being made.

> There are 2 modules where npm's culture of "tiny modules because the stdlib is impoverished" holds - but the issue isn't TC39 really. There are 312 modules that aren't related to npm's culture of "tiny modules because the stdlib is impoverished".

Ah, yeah, I think that is a fair call and I mostly agree with it. "The stdlib is impoverished" argument has changed a lot since the "leftpad" days. So much so it has started to feel more like "the stdlib was impoverished for too long" (and/or "Node was too slow to adopt Browser platform stdlib features and accidentally forked the stdlib for too long"). Most of the damage happened in the past, but a lot of those libraries remain in the ecosystem as developers are slow to adopt new platform features or switch away from old "comfortable" libraries (timeago.js or slice.js versus more vanilla approaches; the quibbling above wasn't entirely tangential, I suppose).

But also the proliferation of modules in npm goes far beyond that. Of course there are a lot of blockchain libraries that will never be stdlib. Of course there are client modules to proprietary APIs that will never be stdlib. The giant size of the npm ecosystem includes a lot more than just "stdlib" style libraries.

I even think the "leftpad" debacle itself did a lot to accelerate npm out of the "tiny modules" approach in general. It also may have itself been a sign that that attitude was already dying. (It was caused by one of the earliest and most prolific "tiny modules" authors leaving the ecosystem in a huff because the ecosystem was changing.)

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#232

Post by freakynit »

michalsustr wrote: post #59
Havoc wrote: post #53

Pretty wary of the entire JS/nodejs ecosystem at this stage.

Given general software quality of the js ecosystem, the proliferation of supply chain attacks was just matter of time. I’m curious how other ecosystems will hold (eg Rust)

And now, vibe-coding is just gonna take this to a whole another level.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#233

Post by btown »

zahlman wrote: post #193
btown wrote: post #113

At a certain point, is it better to just turn off Dependabot and freeze all NPM packages (minor/patch version and all), rather than continuously update? Particularly for frontend packages, meaningful security fixes seem less likely than supply chain attacks these days. It's a sad state of affairs, for sure - but is there a reason we can't just switch our frontends to static BOMs, and trust that NPM at least gets thei…

> and trust that NPM at least gets their "you can't republish to an old version" bare-minimum constraint right? ... Does NPM not create full lockfiles, with hashes and pinned transitive dependencies and everything?

Yes, and the problem here is that most projects have automated systems that automatically update those lockfiles on every upstream release of a library, under an assumption that minor releases are either security patches or bugfixes that would immediately be useful to the consuming project.

IMO this is built on a pre-ShaiHulud, pre-AI set of assumptions, and should be evaluated from first principles with today's security situation.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#234

Post by joshkel »

kommunicate wrote: post #225
bakugo wrote: post #219

Earlier quoted context omitted.

Is there anything about npm that makes it particularly susceptible to these attacks, other than the fact that it's the most popular package manager of all?

npm can execute code after install and most package managers don't do that

I'm far from an expert, but this feels like an oversimplification.

Python packages traditionally use setup.py to install code, and setup.py is all executable code under the installed package's control.

Native Ruby Gems execute arbitrary code via extconf.rb.

Pre .NET Core, NuGet packages could ship scripts like `install.ps1`. That's been removed, but they can still ship `.targets` and `.props` files that are incorporated into your build (and so can run code at build time).

PHP Composer packages can ship install scripts or configure themselves as Composer plugins.

The venerable .tar.gz approach to packaging, covering decades of C and C++ code, is all about executing code during installation.

There are measures that can help (e.g., PHP Composer doesn't run install scripts of _transitive_ dependencies) but the JS space is adopting measures that can help too (like pnpm's approve-builds).

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#235

Post by hirako2000 »

tomxor wrote: post #230

At this point lifecycle script should be disabled by default in NPM. It's a convenience feature that provides built-in Arbitrary Code Execution (even for transient dependencies), and every one of these widespread NPM worm style attacks has propagated through it, because of the default setting. Also enabling it for one command shouldn't automatically permit all transient dependencies to run lifecycle scripts, it shoul…

Or simply use pnpm.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#236

Post by jon-wood »

a1o wrote: post #177
ruined wrote: post #163

Earlier quoted context omitted.

at amazon, they maintain a private internal registry of packages with approved licenses and audits. this has been in place for several years. i assume other big corps enforce similar policies

Do you know if they are using any product like JFrog for this or rolling their own?

This is Amazon, the company where the stuff they rolled their own now makes more money than the business it was rolled for: https://aws.amazon.com/codeartifact/

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#237

Post by MadnessASAP »

freakynit wrote: post #223
bakugo wrote: post #219

Earlier quoted context omitted.

Is there anything about npm that makes it particularly susceptible to these attacks, other than the fact that it's the most popular package manager of all?

Yep. 1. Every day there's a new package. 2. Then five more packages appear so you don't have to write that one terrifying line of JavaScript yourself. 3. Then someone writes a wrapper around those five packages. 4. Then someone writes a "modern, lightweight, zero-config" wrapper around the wrapper. 5. Then a framework adopts it, a build tool requires it, and suddenly your todo app has a dependency graph that looks li…

> 7. Half the packages are maintained by one person, unpaid, at 2 a.m., after getting yelled at in GitHub issues.

By a manager for for a >$1 billion market cap corporation who doesnt understand that the one person isnt an employee.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#238

Post by tadfisher »

michalsustr wrote: post #59
Havoc wrote: post #53

Pretty wary of the entire JS/nodejs ecosystem at this stage.

Given general software quality of the js ecosystem, the proliferation of supply chain attacks was just matter of time. I’m curious how other ecosystems will hold (eg Rust)

NPM is an easy target because every package has the capability of interacting with your development environment by default, via pre/post-install scripts. Cargo has something similar with build.rs scripts, as does Cabal (Haskell).

In JVM-land, thanks to binary distribution being the default, the number of packages you can usurp to achieve the same compromise is fairly small; essentially Maven and Gradle plugins. Which is why you should be extremely wary when, say, Sentry tells you to add them as a dependency by setting up their Gradle plugin. Not sure about sbt. Clojure source dependencies can provide "prep" scripts, which are not automatically run as part of a build, but still execute code on your machine.

There's a pattern here: some build tools incorporate dependency-provided code as part of the consumer project's build, and that is a juicy attack surface. Packages which include such code, or are recently updated to include it, should be treated with extra scrutiny.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#239

Post by notnullorvoid »

Rohansi wrote: post #144
perkovsky wrote: post #96

Earlier quoted context omitted.

Agree. Postinstall scripts should be explicit opt-in, not ambient capability. Most packages should not need arbitrary code execution during install. And when they do, that should be obvious during review. The default should probably be: install files, don’t run code.

If postinstall scripts are restricted the people behind these attacks will switch to something else. Package code is executed automatically by Node when imported, which could be a good replacement. It'll probably run when tests run instead but it's still going to run for most people.

Limiting post install as an attack vector is still a good thing.

Node is working on a similar permission model to Deno that allows explicitly granting certain system resource permissions https://nodejs.org/api/permissions.html. Using it should help reduce impact from malicious code, though if you allow wide permissions it's unlikely to help.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#240

Post by tialaramex »

cuuupid wrote: post #183
tialaramex wrote: post #156

Earlier quoted context omitted.

The "No way to prevent this" analogies seem to me to work better for Memory Safety because, as with Gun Safety, the simple fact is that everybody knows how to solve the problem, but one group insists it's impossible. There is crowing from the "Actually copy-paste is better" people when this happens, but when it's their turn they just jam their fingers in their ears. The memory safety and gun safety problems are the a…

I'll disagree because the primary issues with gun control in the US are: [1] Guns are a core part of culture for much of America, very deeply so outside coastal cities. Most of the left wing in the US lives in coastal cities and either grew up there or immigrated very recently and does not leave, so this is an alien concept to them, but even in very blue cities like D.C. you would be shocked how many liberal democrat…

The whole reason this joke works is because of exactly your belief that somehow you're different and the solution which works for everybody else can't work for you. Charlie is always going to try to kick the ball and Lucy is always going to pull it away and Charlie will never learn from this experience no matter how often it is repeated.
Post reply on HN