Installing any npm packages seems more and more like walking through the minefield at this point.
Postmortem: TanStack NPM supply-chain compromise
181–190 of 501 posts
Re: Postmortem: TanStack NPM supply-chain compromise
#182Am 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?
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 permissions.
The broader permissions of pull_request_target are supposed to be mitigated by the fact that pull_request_target jobs run in a checkout of your current default branch rather than on a checkout of the opened PR. For example, if someone opens a PR from some branch, pull_request_target runs on `main`, not on the new branch. The compromised action, however, checked out the source code of the PR to run a benchmark task, which resulted in running malicious attacker-controlled code in a context that had sensitive credentials.
The GHA docs warn about this risk specifically:
> Running untrusted code on the pull_request_target trigger may lead to security vulnerabilities. These vulnerabilities include cache poisoning and granting unintended access to write privileges or secrets.
They also further link to a post from 2021 about this specific problem: https://securitylab.github.com/resources/github-actions-prev.... That post opens with:
> TL;DR: Combining pull_request_target workflow trigger with an explicit checkout of an untrusted PR is a dangerous practice that may lead to repository compromise.
The workflow authors presumably thought this was safe because they had a block setting permissions.contents: read, but that block only affects the permissions for GITHUB_TOKEN, which is not the token used to interact with the cache. This seems like the biggest oversight in the existing GHA documentation/api (beyond the general unsafety of having pull_request_target at all). Someone could (and presumably did!) see that block and think "this job runs with read-only permissions", which wasn't actually true here.
Re: Postmortem: TanStack NPM supply-chain compromise
#183Earlier 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.
There numerous ways to root Linux over the decades
Re: Postmortem: TanStack NPM supply-chain compromise
#184Earlier quoted context omitted.
React Query is great. I’ve used his router and table component as well. IMO his stuff became popular on merit more than some cargo culting à la redux
as someone who encountered this cargo culted at a number of start ups -- I beg to differ. React Query I will always pass on. the other lesser known hits of tanstack -- won't even consider.
React Query I've managed to avoid but it's really a cache + promise hook, it's fairly versatile.
Tanstack Start / Router are pretty great coming from nextjs, and not limited to React either.
Re: Postmortem: TanStack NPM supply-chain compromise
#185Release pipeline should probably run completely isolated from the main GitHub project.
Maybe a private project, that can't share any cache from the main project where public development is done.
Also only the publish step itself should have access to the publish tokens, and shouldn't run any of the code from the repo. Just publish the previously built tarball, and do nothing more. This would still allow compromising the package somehow in the build step, but at least stealing tokens should become impossible.
Re: Postmortem: TanStack NPM supply-chain compromise
#186No way to prevent this, says only package manager where this regularly happens.
Re: Postmortem: TanStack NPM supply-chain compromise
#187TanStack? Jia Tan? Who is falling for this???
its a cult in react web dev circles. Just be glad that you never had to encounter devs who insist that everything must be on "tan" stack.
Yeah and it’s also ridiculous. They have so many bloated micro-libraries, they have a “headless range” library for controlling ranges and sliders that is marketed as being tiny at only 10kb. And their website is full of glitches and rendering bugs and it takes multiple seconds to navigate pages.
Re: Postmortem: TanStack NPM supply-chain compromise
#188Earlier quoted context omitted.
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?
For the stuff in more sensitive deployments it's really quite simple, just setup CORS etc properly and don't do anything overly fancy on the frontend. Worst case the user may force some internal function to eval some JS by pasting scripts into the browsers debug console.
Critical severity vulnerabilities are only critical when they are reachable, but are completely meaningless if your application doesn't touch that code at all. It's objectively more risky to "patch" those by updating dependencies than just let them be there.
Re: Postmortem: TanStack NPM supply-chain compromise
#189This is another indicator that "lifecycle" scripts in NPM (or other packaging systems, except perhaps Debian or RPM) are an idea we need to learn to live without. At most, packages should be able to emit a message to the user asking them to invoke a one-liner if a setup action is truly necessary.
As a side benefit, eliminating package scripts will contribute toward reproducibility of Docker and VM images.
I realize this will be a controversial opinion.
Re: Postmortem: TanStack NPM supply-chain compromise
#190[flagged]