Live data from Hacker News

Postmortem: TanStack NPM supply-chain compromise

tanstack.com

441–450 of 501 posts

Re: Postmortem: TanStack NPM supply-chain compromise

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

At least my password won't leak as often with yubikey, but the attacker can still hack my shell to execute fake sudo. Even if I type /bin/sudo explicitly, there is ptrace, LD_PRELOAD or just replacing the entire bash binary.

In practice yubikey sudo keeps you much safer today, as almost nobody uses it and malware won't be prepared for it

Re: Postmortem: TanStack NPM supply-chain compromise

#442
post #270
post #241

Earlier quoted context omitted.

I'm not quite sure of what this really accomplishes, like is it just M.A.D.? Like at that point the creds have been stolen and the whole machine is toast.

The point is to dissuade mass token revocations. Let's say the attack becomes hugely succesful and the worm spreads to thousands of devices. GitHub/NPM could just revoke all compromised tokens (assuming they have a way to query) stopping the worm in its tracks. But because of the Dead Mans Switch, they'd know that in doing so, they'd be bricking thousands of their user's devices. So it effectively moves the responsib…

brilliant. thank you for that.

Re: Postmortem: TanStack NPM supply-chain compromise

#444

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

That is not done because then it would be slow.

I don’t think that’s a very strong argument, but that’s the rationale for not having simpler, no-state-shared-between-runs pipelines everywhere I have worked.

Re: Postmortem: TanStack NPM supply-chain compromise

#446

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

Re: Postmortem: TanStack NPM supply-chain compromise

#448
Open-source projects need a home with a coherent trust model for CI and release workflows. It's ridiculous that this kind of cache poisoning is even possible, and that it's the responsibility for each team to audit their configuration N different ways instead of Microsoft's responsibility to run a platform that works right. We have no hope of getting away from situations like this if everyone stays on GHA.

Re: Postmortem: TanStack NPM supply-chain compromise

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

[deleted]

Re: Postmortem: TanStack NPM supply-chain compromise

#450
post #218

Earlier quoted context omitted.

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

Yeah, all left pad incident showed was that NPM cares more about their corporate users than open source developers.
Post reply on HN