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

381–390 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#381

Post by Hamuko »

LelouBil wrote: post #368

pull_request_target is really a landmine.

I'm shocked that big open-source projects are even using it. I was reading through the Actions documentation recently and it did make it pretty clear that you should not be using it for untrusted code.

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

https://docs.github.com/en/actions/reference/workflows-and-a...

Re: Postmortem: TanStack NPM supply-chain compromise

#382

Post by mplanchard »

Ciantic wrote: post #352

What I want to focus on is mental model of your CI pipeline, and problem with too much YAML, consider this quote: > Cache scope is per-repo, shared across pull_request_target runs (which use the base repo's cache scope) and pushes to main. A PR running in the base repo's cache scope can poison entries that production workflows on main will later restore. This is very difficult to understand, and teach to new people,…

I like a lot about nix, and this is one of those things: built derivations are addressed by the hash of their inputs: without changing something about the inputs, you (barring bugs) cannot get an incorrect or poisoned cache artifact

Re: Postmortem: TanStack NPM supply-chain compromise

#383

Post by christophilus »

omcnoe wrote: post #143
getcrunk wrote: post #63

I think we are at the point where everyone really needs to run each project in its own vm. Given the recent lpe vulns docker 100% won’t cut it. And containers were never meant primarily as a security boundary anyways

Devcontainers (I know it's not a full VM, but it's most prominent version of this "isolated development environment" concept) wouldn't fully protect you against this. Github credentials are automatically pulled into the container. If you are using other cloud services that need to be accessed within the container, this cred stealer will grab their creds too. It would limit the blast radius, which at least is an impro…

This is one reason I have my own dev container script. And the container pulls nothing in except whatever I explicitly put in my .podman folder. It runs without any GitHub access at all. I do all of that from the host machine.

Re: Postmortem: TanStack NPM supply-chain compromise

#384

Post by [deleted] »

shevy-java wrote: post #367
cube00 wrote: post #41

Please be careful when revoking tokens. It looks like the payload installs a dead-man's switch at ~/.local/bin/gh-token-monitor.sh as a systemd user service (Linux) / LaunchAgent com.user.gh-token-monitor(macOS). It polls api.github.com/user with the stolen token every 60s, and if the token is revoked (HTTP 40x), it runs rm -rf ~/. https://github.com/TanStack/router/issues/7383#issuecomment-...

> as a systemd user service Hah! I know why I don't use systemd.

[deleted]

Re: Postmortem: TanStack NPM supply-chain compromise

#387

Post by hombre_fatal »

riknos314 wrote: post #177
ghost_pepper wrote: post #135

Earlier quoted context omitted.

yes, they used pull_request_target for a benchmarking suite. github has a huge warning saying to never use pull_request_target to run user code, but this is just going to keep happening

> github has a huge warning saying to never use pull_request_target to run user code This is an area where documentation is necessary but not sufficient. Github needs to add some form of automated screening mechanism to either prevent this usage, or at the very least quickly flag usages that might be dangerous.

"pull_request_target" vs "pull_request" is also bad naming. At least give it a dangerous name so people know there's a dangerous quirk to it when reading their config.

Re: Postmortem: TanStack NPM supply-chain compromise

#389

Post by Yokohiii »

Ciantic wrote: post #352

What I want to focus on is mental model of your CI pipeline, and problem with too much YAML, consider this quote: > Cache scope is per-repo, shared across pull_request_target runs (which use the base repo's cache scope) and pushes to main. A PR running in the base repo's cache scope can poison entries that production workflows on main will later restore. This is very difficult to understand, and teach to new people,…

Fully agree. I was very confused trying to understand the attack.

There are so many things involved that a casual user will never get security right. Even if you are knowledgeable it's very draining if you have to catch up, securing all your workflows is hard work that is definitely NOT done at a glimpse and you probably postpone it because of that.

If you have some sense for security you will usually get nervous doing something stupid in a bash script. Well, except you bury everything in thousands of abstractions.

Re: Postmortem: TanStack NPM supply-chain compromise

#390

Post by FooBarWidget »

lrvick wrote: post #361
FooBarWidget wrote: post #321

Earlier quoted context omitted.

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.

Neither would actually help in this case though. Malware could manipulate both of those as an unprivileged user to run malicious code the next time you elevate privileges. Remember that malware can replace or modify your shell

No? The shell must be listed in /etc/shells, it can't be an arbitrary command. And after elevating privileges you have to run the malware (which could only be written to home or tmp) for it to work, but sudo already scrubs the environment.

So the main danger is that you're not running the real sudo.

I have an idea that I hope to implement one day to make sudo actually secure:

1. Authenticate with passkeys (webauthn) instead of passwords.

2. Sudo can only run an interactive root shell, not arbitrary commands. The session is time-bound, and the TTY output is recorded for auditing purposes.

This combination makes intercepting sudo largely useless. Passkey authentication cannot be replayed or relayed. The fact that sudo can only open an interactive shell makes it impossible for a sudo wrapper to pass a malicious to sudo. This way we're not dependent on whether the unprivileged shell is secured properly. It also solves approval fatigue (compared to running sudo separately for every command).

----

EDIT: now that I think about it: an attacker can still edit .bash_profile and reexec the shell in a malicious terminal emulator. Then when the user gets a sudo root shell, the malicious terminal emulator can inject malicious commands.

Looks like the only good way is to get a root privileges via a separate user account that doesn't have malware, and that also can't easily install malware (e.g. accidentally running npm, forgetting that that's not safe).

Post reply on HN