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

391–400 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#391

Post by ssanderson11235 »

corvad wrote: post #244
827a wrote: post #167

Am I understanding this attack vector correctly: Did tanstack have anything misconfigured on their github or make any mistakes that led to this happening? This is the second time, at least, the github actions cache has been seemingly detrimental to massive and widespread supply chain compromise; what is going on over there?

At least my naive brain wonders if blocking force pushes to main would have stopped this as it is a setting in Github these days, unless I am misunderstanding the final attack vector since it seems it was force pushed.

Noone force-pushed to main in the actual repo. The attacker force-pushed to main in their own fork, but the actual repo had a CI job configured that ran code from the fork in response to changes in that fork.

Re: Postmortem: TanStack NPM supply-chain compromise

#392

Post by antihero »

sophiabits wrote: post #206
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

I would prefer my builds to break than the ecosystem to be compromised.

That said, once unpublished the version should be permanently unavailable to prevent publishing over known good versions.

Re: Postmortem: TanStack NPM supply-chain compromise

#393

Post by [deleted] »

anthk wrote: post #375
lrvick wrote: post #335

Earlier quoted context omitted.

A simple LD_PRELOAD command can cause your shell to run "rm -rf /" when you type "/sudo". If your unprivileged user is compromised, you are pretty hosed.

It should be a way to make system env vars (profile.d or simlar) as readonly so every users' shell had these set to empty values and unable to change them.

[deleted]

Re: Postmortem: TanStack NPM supply-chain compromise

#394

Post by Yokohiii »

ricardobeat wrote: post #324
jonchurch_ wrote: post #173

Earlier quoted context omitted.

The compromised action here was using pnpm. They poisoned the github action cache, which was caching the pnpm store. The chain required pull_request_target on the job to check bundle size, which had cache access and poisoned the main repo’s cache The malicious package that was publisjed will compromise local machines its installed in via the prepare script, though.

Those are two different attack vectors. The exploit they used on Github Actions would work for either npm or pnpm. But the replication part using postinstall scripts, once it is installed on another machine, would be stopped by pnpm. What I'm curious about is: how can you poison the cache in CI, if the lockfile has an integrity hash for each package? Did the incoming PR modify pnpm-lock.yaml? If so, that would an obv…

From what I understand they've wrote the poisoned payload directly to the file system where they've expected another package exists. You only need to know what hash is going to be created.

Re: Postmortem: TanStack NPM supply-chain compromise

#395

Post by codedokode »

All of this happens because Linux doesn't have sandboxing built-in, and sandboxes on Linux are extremely difficult to build (if you want to have graphics and GPU access, sound, file access from sandbox and prevent access to hardware identifiers and serial numbers). Linux has sandboxes like flatpak, but they are leaky (flatpak grants access to /proc and /sys) and buggy (software like Steam inside flatpak sandbox has multiple bugs).

It is bad that Linux users simply run whatever they downloaded from Github with full privileges, it is like an invitation for the hackers. And if you look at installation guides for commercial software, many of them suggest that you run curl + sudo or add a new repository source into a package manager, both of which are bad security practices. Except for flatpacks, Linux has no friendly and secure methods to install commercial software. Despite the fact that users buy computers to run software and not to merely stare at desktop background.

Compare this to Android where you can run malware and it cannot do anything except for annoying you with notifications.

Re: Postmortem: TanStack NPM supply-chain compromise

#396

Post by padjo »

So in summary:

- a writable shared global cache is made available to PRs opened from forks by randomers.

- that cache is reused in the deploy pipeline

- deploys can be made with a single authentication factor, stored on the CI server

- the repository apparently does nothing to check for malicious deploys, delegating that to 3rd parties to do after the code is in the wild.

- by default the package manager runs random code when a package is updated

What a world we live in.

Re: Postmortem: TanStack NPM supply-chain compromise

#397

Post by tyteen4a03 »

tombh wrote: post #318
tyteen4a03 wrote: post #273

Because there’s no guide on how each package manager sets their minimumReleaseAge and every package manager uses a different format… (can we please get a standards committee going for security-related configs like these?) Note: unless otherwise specified, X is a number ONLY. No date units (don’t specify 7d or 1440m. Your config will error.) And for the love of your favourite deity, remove all carets (^) from your pac…

I don't know if this is related. But I've been confused as to whether these recommendations are for package-specific configs, or for system-wide home directory configs (~/.npmrc for example)? Or maybe both?

Both, although if you put it in the repo, it will apply to all users that clone your repo.

Re: Postmortem: TanStack NPM supply-chain compromise

#398

Post by LelouBil »

Hamuko wrote: post #381
LelouBil wrote: post #368

pull_request_target is really a landmine.

I'm shocked that big open-source projects are even using it. I was reading through the Actions documentation recently and it did make it pretty clear that you should not be using it for untrusted code. > Running untrusted code on the pull_request_target trigger may lead to security vulnerabilities. These vulnerabilities include cache poisoning and granting unintended access to write privileges or secrets. https://doc…

I feel like GitHub should deprecate it and replace it with pull_request_untrusted or something and have every shareable aspect (like cache or secrets) an explicit boolean opt-in

Re: Postmortem: TanStack NPM supply-chain compromise

#399

Post by mort96 »

chrisweekly wrote: post #40

Postinstall scripts are deadly. Everyone should be using pnpm. Crazy that an "orphan" commit pushed to a FORK(!) could trigger this (in npm clients). IMO GitHub deserves much of the blame here. A malicious fork's commits are reachable via GitHub's shared object storage at a URI indistinguishable from the legit repo. That is absolutely bonkers.

It's extremely rare that I install a dependency without executing code from it shortly after. I think postinstall scripts are unfortunate and an anti-pattern, but I don't realistically think that their removal would do very much to avoid these kinds of attacks.

Re: Postmortem: TanStack NPM supply-chain compromise

#400

Post by corvad »

ssanderson11235 wrote: post #391
corvad wrote: post #244

Earlier quoted context omitted.

At least my naive brain wonders if blocking force pushes to main would have stopped this as it is a setting in Github these days, unless I am misunderstanding the final attack vector since it seems it was force pushed.

Noone force-pushed to main in the actual repo. The attacker force-pushed to main in their own fork, but the actual repo had a CI job configured that ran code from the fork in response to changes in that fork.

Ah that makes more sense I was kind of confused by that.
Post reply on HN