Live data from Hacker News

Postmortem: TanStack NPM supply-chain compromise

tanstack.com

161–170 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#161

Appreciate the tanstack postmortem, however the security issue as far as the rest of the npm ecosystem goes is still an ongoing concern, correct? Is there evidence that any downstream packages that may have pulled/included tanstack packages should be considered safe?

NPM is getting all the attacks and attention because it is the biggest. But there's nothing language specific to this class of attacks.

Re: Postmortem: TanStack NPM supply-chain compromise

#162

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.

On linux realistically whatever user you installed the malicious NPM package with has access to everything you care about anyway.

Re: Postmortem: TanStack NPM supply-chain compromise

#163
post #139
post #88

Earlier quoted context omitted.

This sort of mitigation seems like it makes sense in the short term, but it seems like it would only work as long as most people don't do it. If everyone has this set to seven days, it will take seven days plus three hours to get things yanked, and then there will be people who will set to 14 days...

These malicious packages are being caught by the authors, and by automated package security scanners, not just by end users. npm should start setting this 7 day cooldown as default.

Even 12 hours would probably be enough. Those automatic malware scanning companies are getting really fast.

Re: Postmortem: TanStack NPM supply-chain compromise

#164

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'm looking forward to the analysis how the attacker managed to compromise CI. I was reading through the workflow and what immediately jumped out was a cache poisoning attack. Seems plausible, given https://github.com/TanStack/config/pull/381 edit: two hard things in computer science: naming things, cache invalidation, off-by-one errors, security. something something

Yes it is a GitHub actions cache poisoning attack

Re: Postmortem: TanStack NPM supply-chain compromise

#165
post #7

Earlier quoted context omitted.

Abandon NPM in exchange for what? Cargo? Go get? Pip install? Every package manager that does not analyze and run tests on the packages being uploaded (like Linux distros do) is vulnerable.

Even linux was subjected to an attack in xz utils. Granted it is much harder and they have a much better auditing problem (something npm should learn from). There really isn't a silver bullet here unfortunately. The industry as a whole needs to get more serious about this.

but it was caught with the existing release model, where first it goes to testing where many people before reaching the production systems in the stable release. for example debian

Re: Postmortem: TanStack NPM supply-chain compromise

#166

Earlier quoted context omitted.

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.

”TanStack maintainer Tanner Linsley said the attacker used an orphaned commit to gain access to the workflow run that stores the OIDC token, effectively bypassing the project’s existing publishing protections. He noted that two-factor authentication is enabled for everyone on the team”

2fa being enabled for people on the team is different from 2fa being required for publishing. It is not current possible to enforce (or use) 2fa for publishing with trusted publishing.

Re: Postmortem: TanStack NPM supply-chain compromise

#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?

Re: Postmortem: TanStack NPM supply-chain compromise

#168
post #104

TanStack? Jia Tan? Who is falling for this???

Can you explain further? TanStack has popped up in our apps and I don't know why I should not be falling for this or what exactly the "this" is that is being fallen for.

It's a joke that apparently wasn't well received by HN.

Re: Postmortem: TanStack NPM supply-chain compromise

#169

1. _Multiple third-party companies_ can detect these obviously malicious packages in almost-real-time 2. NPM still not only publishes them, but also keeps distributing them for anything beyond 5 minutes. Microsoft/GitHub/NPM can only keep repeating "security is our top priority" so many times. But NPM still doesn't detect these simple attacks, and we keep having this every week.

It'll always be a cat-and-mouse game. If npm adds protections, it'll only yield false-positives and workarounds will be trivial.

Re: Postmortem: TanStack NPM supply-chain compromise

#170
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.

It's the "nuke it from orbit" approach but "the only way to be sure".
Post reply on HN