[dead]
Postmortem: TanStack NPM supply-chain compromise
451–460 of 501 posts
Re: Postmortem: TanStack NPM supply-chain compromise
#452The Mini Shai-Hulud worm is actively compromising legitimate npm packages by hijacking CI/CD pipelines and stealing developer secrets. StepSecurity's OSS Package Security Feed first detected the attack in official @tanstack packages and is tracking its spread across the ecosystem in real time.
How did you guys detect it? Do you use it internally or do you monitor popular packages?
We have built an AI Package Analyst https://app.stepsecurity.io/oss-security-feed and also monitor them using https://github.com/step-security/harden-runner for runtime behavior.
Re: Postmortem: TanStack NPM supply-chain compromise
#453Earlier quoted context omitted.
[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.
There a million ways that malware can persist without root.
And I'm increasingly concerned that one could vibe-code a massive payload that does all of these at once - including subtle things like trying to get itself installed into personal projects and forks, so it can persist across a system wipe. We're only seeing the beginning of these attacks.
Re: Postmortem: TanStack NPM supply-chain compromise
#454Earlier quoted context omitted.
> Sudo is security theater. Yes indeed. > Malware can make a fake unprivileged sudo that sniffs your password. Not on my Linux workstation though. No sudo command installed. Not a single setuid binary. Not even su . So basically only root can use su and nobody else. Only way to log in at root is either by going to tty2 (but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so…
This thread was kicked off by somebody who said: > Realistically if you have installed malware, you need to do a full wipe of your computer anyway You might be the exception to this sentiment. But out of curiosity, after all that setup would you feel confident trying to recover from malware (rather than taking the “nuke it from orbit” approach?).
> But out of curiosity, after all that setup would you feel confident trying to recover from malware (rather than taking the “nuke it from orbit” approach?).
Oh no, I'd still nuke everything from orbit should I find anything indicating a local exploit succeeded. But the thing is: if on one system a local exploit has less probability to give root, then the probability that on that same system I'd know I need to nuke everything from orbit would be higher than on a system where root is easier to obtain.
I was however answering to the part about subverting sudo: and I both agree (it's totally trivial to abuse sudo) and disagree ("everybody uses sudo") with the part about sudo.
Re: Postmortem: TanStack NPM supply-chain compromise
#455Earlier quoted context omitted.
> Sudo is security theater. Yes indeed. > Malware can make a fake unprivileged sudo that sniffs your password. Not on my Linux workstation though. No sudo command installed. Not a single setuid binary. Not even su . So basically only root can use su and nobody else. Only way to log in at root is either by going to tty2 (but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so…
FYI, in English the phrase "since years" is grammatically incorrect and sounds unnatural to a native speaker's ears. The correct phrase would be "I've been using that setup for years." /aside
> The correct phrase would be "I've been using that setup for years."
Oh TYVM. Native french speaker here so it'd be the literal translation of: "depuis des années".
Weird thing is I'm pretty sure I've read it written like that... for years ; )
Re: Postmortem: TanStack NPM supply-chain compromise
#456Earlier quoted context omitted.
> Sudo is security theater. Yes indeed. > Malware can make a fake unprivileged sudo that sniffs your password. Not on my Linux workstation though. No sudo command installed. Not a single setuid binary. Not even su . So basically only root can use su and nobody else. Only way to log in at root is either by going to tty2 (but then the root password is 30 characters long, on purpose, to be sure I don't ever enter it, so…
Why disallow password login when you have 30 char password?
> Why disallow password login when you have 30 char password?
I only disallow password login over SSH. It's still technically possible to log in at a virtual console (like tty1 / tty2 / etc.) using a password (btw only root has a 30 characters password).
Usually you do not allow to directly log in as root by SSH: but in my case it's basically the way I want it done. So I allow root to log in by using SSH but only with a Yubikey.
Re: Postmortem: TanStack NPM supply-chain compromise
#457Postinstall scripts are deadly. Everyone should be using pnpm. Crazy that an "orphan" commit pushed to a FORK(!) could trigger this (in npm clients). IMO GitHub deserves much of the blame here. A malicious fork's commits are reachable via GitHub's shared object storage at a URI indistinguishable from the legit repo. That is absolutely bonkers.
It's extremely rare that I install a dependency without executing code from it shortly after. I think postinstall scripts are unfortunate and an anti-pattern, but I don't realistically think that their removal would do very much to avoid these kinds of attacks.
You should sandbox where you run the code. The thing is, it's very hard for me to know how to sandbox an install script, but it's actually quite easy (and my responsibility as the app dev) to know how to sandbox my tests/ application.
Re: Postmortem: TanStack NPM supply-chain compromise
#458wow
Re: Postmortem: TanStack NPM supply-chain compromise
#459Earlier quoted context omitted.
> 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 ex…
If I saw this in my CI script: curl -X POST $GITHUB_CACHE_URL It would make me pause, but now that it is a misfeature in YAML configuration it is more widely used. Point of bash scripts they are auditable, and understandable. I didn't prescribe what the bash script would be, because it would differ on use case. If I wanted to share artifacts from other runs I would probably use podman and make sure I start new runs f…
The fundamental problem is that on Github Actions it's possible to give read-only permissions to pipelines that are then violated because runners can be granted read+write permissions to the cache. And they don't consider this a P0 bug.
So you don't even need to see questionable bash scripts to know there's a problem. The script would have already completed and pwned you by the time you see it.
With podman or nix you would have to poison the container registry/nix store which is more difficult, but you're also probably using your own runners.
My point though is that it's not bash or yaml here, but Github's default access controls. If you own your own runners and your own caching layer then you're not going to be nearly as boneheaded as Github here. But Github pushes people towards their integrated solutions, which have horrible defaults.
Re: Postmortem: TanStack NPM supply-chain compromise
#460What do folks here do to avoid having plaintext credentials on disk? I try to use 1Password's plugins where I can. I find the SSH key (and got signing) experience flawless, but the cli experience (eg aws cli) pretty clunky - they often break, and they don't even have a gcp plugin last I checked.
I use `pass` on all my personal dev workstations and phone (because I happen to own YubiKeys/OpenPGP cards with my PGP key on them anyway; would probably use `age`/SOPS instead if I already hadn't committed to the PGP ecosystem). If /usr/bin/bar wants a credential via a FOO_API_KEY environment variable, I create a /usr/local/bin/bar wrapper script like so: #!/bin/bash set -eu +x if [[ -z "${FOO_API_KEY:-}" ]]; then e…
Ooh, that's clever. Thanks for sharing.