The next NotPetya will be an NPM package or Rust crate that no one has ever heard of, but everything depends on through transitive dependencies.
Postmortem: TanStack NPM supply-chain compromise
91–100 of 501 posts
Re: Postmortem: TanStack NPM supply-chain compromise
#92Earlier quoted context omitted.
It's insane to me you spend $200 on a report you likely rarely read in detail or double check for correctness, yet you're doing it to feel good about security.
If it runs in a harness that will alert me when something dodgy is detected I'm fine to stay at that level. I don't read it in detail because reading in detail is precisely what I delegate to the harness. The alternative is that I delegate all this trust to package managers and the maintainers which quite clearly is a bad idea. Whether the $$ pricetag is worth it is.. relative. Also in Go you don't update all that of…
> running few years old JS deps
What do you when a critical vulnerability gets discovered and you have to update a package? How many critical/high severity vulnerabilities are you running with in production every day to avoid supply chain attacks?
Re: Postmortem: TanStack NPM supply-chain compromise
#93Earlier quoted context omitted.
Cargo is spiritually based on NPM so it's not much better. Go Get is closer to always locking dependencies unless you explicitly upgrade them with a go get, so it's much much better in my view. Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go. In Go projects my policy for upgrading dependencies includes running full AI audit of all code changed across all dependencies, come…
> Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go. How is it not the default in npm?
It is the default in both cargo and npm, but "npm install" stupidly enough still updates the lockfile, and you need "npm ci" to actually respect it. I think there's some flag to make install work sanely, but long-term I find the best approach is to use anything other than npm.
I ditched npm for yarn years ago because it had saner dependency resolution (npm's peer dependency algorithm was a constantly moving target), and now I've switched from yarn to bun because it doesn't run hooks in dependencies by default. It also helps that it installs dependencies 10x faster.
Re: Postmortem: TanStack NPM supply-chain compromise
#94Please 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-...
I don't understand why people were voting this comment down in the issue page
[dead]
Re: Postmortem: TanStack NPM supply-chain compromise
#95It 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.
”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”
Re: Postmortem: TanStack NPM supply-chain compromise
#96Earlier 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.
Exactly, the only real way to escape this madness is if we move back to "Standard Libs" where your project only depends on 1-3 core libraries. For example, .NET and Java are almost entire 'kitchen sink' ecosystems. Arguably for simple projects, Go has a fairly large standard lib.
This is exactly why I love Deno so much, it has a standard lib AND a security model that's secure by default.
Re: Postmortem: TanStack NPM supply-chain compromise
#97How likely is it that I have this installed if I'm not a JS developer? It seems like half of the programs on my work computer install their own JS runtime.
Re: Postmortem: TanStack NPM supply-chain compromise
#98 > making it the first documented case of a self-spreading npm worm that carries valid SLSA provenance attestations
Re: Postmortem: TanStack NPM supply-chain compromise
#99Please 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-...
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.
Re: Postmortem: TanStack NPM supply-chain compromise
#100Earlier quoted context omitted.
Only if the goal is to actually spread fear in a civilian population. It's not clear what the motivation is here besides "the worm spreads itself lol".
that dead man's switch surely smells like that tbh
The dead man's switch reminds me of worms and viruses from my childhood, whose primary purpose was apparently just to wreak havoc rather than direct financial gain. It's a childish gimmick.