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

421–430 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#421

Post by jherdman »

lknuth wrote: post #405
ssanderson11235 wrote: post #182

Earlier quoted context omitted.

The fundamental mistake here seems to have been not fully understanding the threat model of the pull_request_target action trigger. pull_request_target jobs run in response to various events related to a pull request opened against your repo from a fork (e.g, someone opens a new PR or updates an existing one). Unlike pull_request jobs, which are read-only by default, pull_request_target jobs have read/write permissio…

Static analyzers like https://github.com/zizmorcore/zizmor can help find such misconfiguration. It is however unfortunate, that such footguns aren't harder to fire.

Many thanks for sharing this. I wasn't aware it existed.

Re: Postmortem: TanStack NPM supply-chain compromise

#422

Post by nightpool »

anthk wrote: post #373
throwaway7356 wrote: post #338

Earlier quoted context omitted.

Yeah, works well: $ /usr/bin/sudo() { echo Not the real sudo.; } $ /usr/bin/sudo Not the real sudo. And every other suggestion also doesn't work if the attacker can just replace the shell.

/usr/bin/sudo isn't evaluated as a function under ksh.

> And every other suggestion also doesn't work if the attacker can just replace the shell.

Re: Postmortem: TanStack NPM supply-chain compromise

#423

Post by webXL »

killerstorm wrote: post #350
jonchurch_ wrote: post #23

It is unfortunate, but this is evidence (IMO) that Trusted Publishing is still ~~not secure~~ not enough by itself to securely publish from CI, as an attacker inside your CI pipeline or with stolen repo admin creds can easily publish. This isnt new information, TP is not meant to guarantee against this, but migrating to TP away from local publish w/ 2fa introduces this class of attack via compomise of CI. (edit: chan…

Yeah, it's kinda weird - it's not like GitHub uses a particular secure stack, formal verification or anything. It's just a regular build server with a power to compromise millions of software packages. Bitcoin people solved problem a decade ago with deterministic build: Bitcoin core is considered publisher when 5+ devs get bit-exact build artifact, each individually signing a hash. Replicating that model isn't hard,…

"Works on my machine" - a colleague's mug from back in the day. He was just being funny, but there's a bit of truth in every joke. Reproducibility was only occasionally a top concern for developers, and then github and other CI tools came along to offload that concern all together. Perhaps with the growing threat maintainers will start to care again. Github should just turn off publishing capabilities and force them to care.

Re: Postmortem: TanStack NPM supply-chain compromise

#424

Post by olejorgenb »

padjo wrote: post #396

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…

And the gotcha has been known about since 2014:

> This is the class of attack documented by Adnan Khan in 2024. It's not a TanStack-specific bug; it's a known GitHub Actions design issue that requires conscious mitigation.

While it seems the maintainers kinda went-out-of-their way to enable this - GitHub could easily have at least turned of cache-sharing between fork jobs and the main jobs...

Re: Postmortem: TanStack NPM supply-chain compromise

#425

Post by k33P1Tr3aL »

cube00 wrote: post #41

Please be careful when revoking tokens. It looks like the payload installs a dead-man's switch at ~/.local/bin/gh-token-monitor.sh as a systemd user service (Linux) / LaunchAgent com.user.gh-token-monitor(macOS). It polls api.github.com/user with the stolen token every 60s, and if the token is revoked (HTTP 40x), it runs rm -rf ~/. https://github.com/TanStack/router/issues/7383#issuecomment-...

Sounds like MSFT should update the WAF to look for this polling and just return 200 or some other code until resolved, then cycle the tokens.

Re: Postmortem: TanStack NPM supply-chain compromise

#426

Post by antihero »

Gigachad wrote: post #136
cube00 wrote: post #41

Please be careful when revoking tokens. It looks like the payload installs a dead-man's switch at ~/.local/bin/gh-token-monitor.sh as a systemd user service (Linux) / LaunchAgent com.user.gh-token-monitor(macOS). It polls api.github.com/user with the stolen token every 60s, and if the token is revoked (HTTP 40x), it runs rm -rf ~/. https://github.com/TanStack/router/issues/7383#issuecomment-...

Realistically if you have installed malware, you need to do a full wipe of your computer anyway.

Yeah, this is pretty good devex from the hackers.

Re: Postmortem: TanStack NPM supply-chain compromise

#427

Post by pprotas »

timwis wrote: post #353
pprotas wrote: post #341

Earlier quoted context omitted.

`sops` combined with `age` is great! Benefit is that it doesn't tie you into 1Password's ecosystem

That looks interesting, but unless I'm missing it, it still leaves you with things like ~/.aws/credentials in plaintext on disk, doesn't it?

Yes, although there are ways around it.

The other commenter mentioned a possible workaround, but you can also authenticate with AWS through env variables. You could store these in sops and have an alias or task that routes your aws commands through sops:

  sops exec-env secrets.enc.yaml 'aws something something' # sops injects decrypted credentials into env vars at runtime

Re: Postmortem: TanStack NPM supply-chain compromise

#428

Post by mort96 »

lrvick wrote: post #358
michaelmior wrote: post #340

Earlier quoted context omitted.

That depends on what the software is. If you want to run a service that bonds to a privileged port for example, you need sudo.

If you set the appropriate linux capabilities flag on a binary such as sshd at bootup then unprivileged users can bind to 22, no problem. setcap 'cap_net_bind_service=+ep' /usr/sbin/sshd Could even run it as a daemon unprivileged from a home directory with "systemd --user" That said if you have multiple users and want every user to have their own sshd reachable on port 22 on the same machine you probably want to list…

How do you setcap without root?

Re: Postmortem: TanStack NPM supply-chain compromise

#429

Post by duped »

Ciantic wrote: post #352

What I want to focus on is mental model of your CI pipeline, and problem with too much YAML, consider this quote: > Cache scope is per-repo, shared across pull_request_target runs (which use the base repo's cache scope) and pushes to main. A PR running in the base repo's cache scope can poison entries that production workflows on main will later restore. This is very difficult to understand, and teach to new people,…

> What if your CI pipeline was old-school bash script instead?

It doesn't matter if the cache is accessed through `actions/cache` in YAML or `curl -X POST $GITHUB_CACHE_URL I cannot fathom why they chose to support this at all, let alone make it the default for any action trigger. Any writeable data should be scoped to users/groups and require credentials. It should be impossible to write to a shared cache without explicitly granting permissions to the user triggering the action.

And sure a PAT might leak through an env var not configured through secrets, but that's an understandable issue created by the user. I think most people are surprised their caches are world writeable with an innocuous actions trigger.

Re: Postmortem: TanStack NPM supply-chain compromise

#430

Post by kro »

eqvinox wrote: post #158
Gigachad wrote: post #136

Earlier quoted context omitted.

Realistically if you have installed malware, you need to do a full wipe of your computer anyway.

[On Linux:] If you didn't give yourself "free" (passwordless) sudo, that's not necessary… …unless it happened in a week with 2 and a half Linux kernel LPEs.

Next easy attack vector is (non-rootless) docker run with rootfs mount, many are in docker group even when sudo is protected. Also, most sensitive data is in the user scope anyways (on a PC).

You should always run dev stuff in containers to start with. And when your system is compromised, reprovision from a higher scope, too many places to hide backdoors

Post reply on HN