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

271–280 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#271

Post by bmandale »

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

Some people would set up tooling to look for compromises the moment they get published. What's neat about this is that as an attacker you have no way to determine beforehand whether you'll get caught by this. So you would run your attack, it would lead to a compromised package being published, then the world would get a chance to look at it and see if they can detect the issue with it. This would of course lead to attackers being a lot sneakier. But I think due to the opaque nature of what checks people are running against packages and what they might notice, a much smaller number of attacks would make it through. Of course the ones that did by definition would be the ones that were impossible to detect and would thus stick around a lot longer.

Re: Postmortem: TanStack NPM supply-chain compromise

#273

Post by tyteen4a03 »

Because there’s no guide on how each package manager sets their minimumReleaseAge and every package manager uses a different format… (can we please get a standards committee going for security-related configs like these?)

Note: unless otherwise specified, X is a number ONLY. No date units (don’t specify 7d or 1440m. Your config will error.)

And for the love of your favourite deity, remove all carets (^) from your package.json unless you know what you are doing. Always pin to exact versions (there should be no special characters in front of your version number)

    npm: In .npmrc, min-release-age=X. X is the number of days. Requires npm v11.10.0 or above.

    pnpm: In pnpm-workspace.yaml, set minimumReleaseAge: X. X is the number of minutes. Requires pnpm v10.16.0 or above. From v11 onwards, the default is 1440 minutes (1 day)

    Yarn: In .yarnrc.yml, set npmMinimalAgeGate: X. X is a duration (date units supported are ms, s, m, h, d, w, e.g. 7d). If no duration is specified, then it is parsed as minutes (i.e. npmMinimalAgeGate: 1440 is equal to npmMinimalAgeGate: 1440m). Requires Yarn v4.10 or above.

    Deno: In deno.json, set "minimumDependencyAge": "X". X can be a number in minutes, a ISO-8601 Duration or a RFC3339 absolute timestamp (basically anything that looks like a date; if you are in Freedom Country remember to swap the month and the date). Requires Deno v2.6.0 or above.

    Bun: In bunfig.toml, set:

      [install]

      minimumReleaseAge = X
X is the number of seconds. Requires Bun v1.3.0 or above.

Re: Postmortem: TanStack NPM supply-chain compromise

#274

Post by sheept »

yetanotherjosh wrote: post #117
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.

How is this not a Github P0? Can anyone explain? When I read that, I thought they must be using 'fork' wrong, and actually mean branch on the official repo, as that can't be right!?" Good lord.

In some cases, you can also use forks to read commits from private forks[0], but GitHub considers these linked commit networks working as intended.

[0]: https://trufflesecurity.com/blog/anyone-can-access-deleted-a...

Re: Postmortem: TanStack NPM supply-chain compromise

#275

Post by 9dev »

andix wrote: post #185

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

That's the case if you use pull_request rather than pull_request_target.

Re: Postmortem: TanStack NPM supply-chain compromise

#279

Post by [deleted] »

Gigachad wrote: post #162
eqvinox wrote: post #158

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

On linux realistically whatever user you installed the malicious NPM package with has access to everything you care about anyway.

[deleted]
Post reply on HN