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”
Postmortem: TanStack NPM supply-chain compromise
151–160 of 501 posts
Re: Postmortem: TanStack NPM supply-chain compromise
#152Earlier quoted context omitted.
I think you missed the joke/sarcasm there.
It's been less than a month since I responded to a comment on a different thread arguing basically the same thing about C/C++ in a serious way. I've long since lost the ability to distinguish.
Re: Postmortem: TanStack NPM supply-chain compromise
#153Earlier quoted context omitted.
Incredible. Mutually assured destruction. The next five years are going to be truly WILD in the software world. Air-gapped systems are gonna be huge.
Maybe just ai-gapped.
Re: Postmortem: TanStack NPM supply-chain compromise
#154It 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…
Re: Postmortem: TanStack NPM supply-chain compromise
#155Reminder 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.
Re: Postmortem: TanStack NPM supply-chain compromise
#156Please 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-...
One should always have had backups configured, but if this is what gets people to setup backups, so much the better.
Re: Postmortem: TanStack NPM supply-chain compromise
#157Earlier quoted context omitted.
I agree with you that TP is an improvement over long lived npm tokens in CI. However, the threat Im most afraid of still does involve dev environment compromise. Because if your repo admin gets their token stolen from their gh cli, they can trivially undo via API (without a 2fa gate!) any github level gate you have put in place to make TP safe. I want so badly to be wrong about that, we have been evaluating TP in my…
Yes, that is the threat I'm most worried about as well. But look at your description of it - a repo admin has to be compromised. Not just "random engineer". Although, in this case, the attacker leveraged a cache poisoning attack to move into the privileged workflow and I suspect this sort of thing will be commonplace. I'm in agreement that a second factor would be ideal, to be clear. I think it's a good idea, somethi…
There is no gate you can put on a Trusted Publisher setup in github which requires 2fa to remove. Full stop. 2fa on github gates some actions, but with a token with the right scope you can just disable the gating of workflow-runs-on-approve, branch protection, anything besides I think repo deletion and renaming.
And in my experience most maintainers will have repo admin perms by nature of the maintainer team being small and high trust. Your point is well taken, however, that said stolen token does need to have high enough privileges. But if you are the lead maintainer of your project, your gh token just comes with admin on your repo scope.
Re: Postmortem: TanStack NPM supply-chain compromise
#158Please 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.
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.
Re: Postmortem: TanStack NPM supply-chain compromise
#159Earlier 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.
Re: Postmortem: TanStack NPM supply-chain compromise
#160Earlier quoted context omitted.
QubesOS had the right idea. You want layers and layers of security, with multiple VMs at the root.
> had the right idea Is it no longer the right idea?