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

Postmortem: TanStack NPM supply-chain compromise

tanstack.com

Post reply on HN
Print view View original

201–210 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#201

Post by ezekg »

> Unpublish was unavailable for nearly all affected packages because of npm's "no unpublish if dependents exist" policy. We have to rely on npm security to pull tarballs server-side, which adds hours of delay during which malicious tarballs remain installable

Per https://docs.npmjs.com/policies/unpublish:

> If your package does not meet the unpublish policy criteria, we recommend deprecating the package. This allows the package to be downloaded but publishes a clear warning message (that you get to write) every time the package is downloaded, and on the package's npmjs.com page. Users will know that you do not recommend they use the package, but if they are depending on it their builds will not break. We consider this a good compromise between reliability and author control.

I don't even know what to say here, npm.

Re: Postmortem: TanStack NPM supply-chain compromise

#205

Post by arcfour »

lrvick wrote: post #193
nazcan wrote: post #191

Earlier quoted context omitted.

To clarify, when does this run? Like you download malware A, run malware A and this function definition changes sudo for it, or sudo for other cases?

This could for instance be injected into your .bashrc when you do an "npm install" of a package that has a deeply nested supply chain attack. Then the next time you run sudo, phase2 triggers installing a rootkit, etc.

Or you could also hijack it using $PATH search order with your wrapper to get existing terminal sessions too, there's a lot of ways to skin that cat.

Re: Postmortem: TanStack NPM supply-chain compromise

#206

Post by sophiabits »

ezekg wrote: post #201

> Unpublish was unavailable for nearly all affected packages because of npm's "no unpublish if dependents exist" policy. We have to rely on npm security to pull tarballs server-side, which adds hours of delay during which malicious tarballs remain installable Per https://docs.npmjs.com/policies/unpublish : > If your package does not meet the unpublish policy criteria, we recommend deprecating the package. This allows…

I do not envy the position the npm team are in. They removed the ability to unpublish packages as a response to the left-pad incident[1] because it wasn't desirable for individual developers to break downstream dependencies by pulling their package maliciously.

Of course the side effect is that now it's much harder to pull packages for legitimate reasons :/

[1] https://en.wikipedia.org/wiki/Npm_left-pad_incident

Re: Postmortem: TanStack NPM supply-chain compromise

#207

Post by Imustaskforhelp »

jdxcode wrote: post #199
gajus wrote: post #13

Reminder to secure your npm environments. https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f... Just a handful of settings to save a whole lot of trouble.

In aube you get all this out of the box plus a lifecycle jail (next MV will have that on by default) and defaults to trustPolicy=no-downgrade (would not have helped here but still a good default). It has the strongest security posture of any node pm. https://aube.en.dev/security.html#jailed-lifecycle-scripts

What a pleasant surprise to see jdx within comments! I was actually using mise and found aube and decided to publish it on hackernews, I found it really cool!

Though a bit sad that it hadn't received traction back then but I must admit jdx that a lot of the work that you do is really cool.

Also I am happy to know that you are finally able to work on Open source full time, I am glad that I can use open source software created by (in my opinion generous) people like you too, mise is awesome :-D

https://news.ycombinator.com/item?id=48012248

Re: Postmortem: TanStack NPM supply-chain compromise

#208

Post by beart »

AgentME wrote: post #28
rvz wrote: post #22

Earlier quoted context omitted.

And absolutely pin, pin, pin, ALL your dependencies. If I see a package version dependency that looks like this: ^1.0.0 or even this: "*", then stop reading, pin it to a secure version immediately.

Npm's package-lock.json already handles pinning everything to exact versions, including subdependencies. Pinning exact versions in package.json doesn't affect your subdependencies.

You aren't wrong. However, this article does offer some additional advice on this matter, and some potential reasons why it might still be desirable to pin your deps in package.json.

https://docs.renovatebot.com/dependency-pinning/#pinning-dep...

Some exerts:

> If a lock file gets out of sync with its package.json, it can no longer be guaranteed to lock anything, and the package.json will be the source of truth for installs.

> provides much less visibility than package.json, because it's not designed to be human readable and is quite dense.

> If the package.json has a range, and a new in-range version is released that would break the build, then essentially your package.json is in a state of "broken", even if the lock file is still holding things together.

Re: Postmortem: TanStack NPM supply-chain compromise

#209

Post by igregoryca »

ezekg wrote: post #201

> Unpublish was unavailable for nearly all affected packages because of npm's "no unpublish if dependents exist" policy. We have to rely on npm security to pull tarballs server-side, which adds hours of delay during which malicious tarballs remain installable Per https://docs.npmjs.com/policies/unpublish : > If your package does not meet the unpublish policy criteria, we recommend deprecating the package. This allows…

The baffling part is why it takes hours for the npm security team to unpublish packages that contain malware, as attested by multiple independent sources? That should be able to happen in minutes.

Re: Postmortem: TanStack NPM supply-chain compromise

#210

Post by lrvick »

arcfour wrote: post #205
lrvick wrote: post #193

Earlier quoted context omitted.

This could for instance be injected into your .bashrc when you do an "npm install" of a package that has a deeply nested supply chain attack. Then the next time you run sudo, phase2 triggers installing a rootkit, etc.

Or you could also hijack it using $PATH search order with your wrapper to get existing terminal sessions too, there's a lot of ways to skin that cat.

Endless ways, which is why I do not understand why sudo is ever used anymore, especially in production.

You do not need root to do anything in Linux these days anyway between Namespaces and Capabilities so there is really no reason for root to be accessible at all or have any processes running as root post boot.

Post reply on HN