Hacker News

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

It's the "nuke it from orbit" approach but "the only way to be sure".

you're gonna need the infected device as is for forensics

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"

We need a new emoji for: the situation is lame and the poster is correct. Like a combination of thumbs-up+frown

bots.

the GitHub bot law: the GitHub bot situation is way worse than you imagine even if you are aware of the GitHub bot law.

yes, a cheap parody on Hofstadter's law, but that's how bad it is

[dead]

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 have been: “it looks like the payload installs a dead-mans switch…”

Asking the maintainers not to revoke their compromised credentials deserves every down vote it receives.

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 responsibility to revoke compromised tokens from a central authority that could do it en-masse, to each individual who got compromised, greatly improving the worm's chances of survival.

Even after the owner has realized the attack and revoked the token, there’s next steps (alerting the community, pulling from NPM) that causing havoc delays even by just a bit.

Only if the goal is to actually spread fear in a civilian population. It's not clear what the motivation is here besides "the worm spreads itself lol".

Maybe just ai-gapped.

Sure. But even restoring from backup means a cost is being inflicted, and not a small one.

I have not read that blog post. But unfortunately (and I'd love to be wrong!) it doesn't matter for if a repo admin's token gets exfiled, because if you put your gates within Github, an admin repo token is sufficient to defang all of them from the API without 2fa challenge.

That is why I want 2fa before publish at the registry, because with my gh cli token as a repo admin, an attacker can disable all the Github branch protection, rewrite my workflows, disable the required reviewers on environments (which is one method people use for 2fa for releases, have workflows run in a GH environment whcih requires approval and prevents self review), enable self review, etc etc.

Its what I call a "fox in the hen house" problem, where you have your security gates within the same trust model as you expect to get stolen (in this case, having repo admin token exfiled from my local machine)

”TanStack maintainer Tanner Linsley said the attacker used an orphaned commit to gain access to the workflow run that stores the OIDC token, effectively bypassing the project’s existing publishing protections. He noted that two-factor authentication is enabled for everyone on the team”

The way I see it - if you're pushing a change to an NPM package with more than [N] daily downloads/downstream packages, and you don't have a human online who's able to approve a two-factor for the release on their phone... then you also don't have a human online who's able to hotfix or rollback in case of a breaking bug, much less a compromise. Even setting security aside - that's in service of a stable ecosystem.

And the two-factor approver should see a human-written changelog message alongside an AI summary of what was changed, that goes deeply into any updated dependencies. No sneaking through with "emergency bugfix" that also bumps a dependency that was itself social-engineered. Stop the splash radius, and disincentivize all these attacks.

Edit: to the MSFT folks who think of the stock ticker name first and foremost - you'd be able to say that your AI migration tools emit "package suggestions that embed enterprise-grade ecosystem security" when they suggest NPM packages. You've got customers out there who still have security concerns in moving away from their ancient Java codebases. Give them a reason to trust your ecosystem, or they'll see news articles like this one and have the opposite conclusion.

Because it does. The attack has to involve the CI pipeline rather than the dev environment, there's no token to revoke after (if you evict the attacker you're done, the OIDC credentials expire), it's easier to monitor for externally, you can build things like branch protections in and isolate things like "run tests" from "publish", etc. Trusted Publishing is not itself a solution to all supply chain issues but it is a massive improvement.

Yes it is a GitHub actions cache poisoning attack

Almost all these recent compromises seem to involve either cache poisoning or prompt injection via untrusted variables.

I think it was an afterthought in the design. CI cache should be scoped per-user, or at least per-group.

If a workflow run by a maintainer (with access to secrets) can pull a cache tarball uploaded by a random user on GitHub, then it’s a security black hole. More incidents like this are inevitable.

Yes, but the exploit was with Github Actions not something that pnpm really prevented.

In some cases, you can also use forks to read commits from private forks[0], but GitHub considers these linked commit networks working as intended.

[0]: https://trufflesecurity.com/blog/anyone-can-access-deleted-a...

If git in general would enforce pretending to not know about orphans, it would always need to know what you were meaning to consider the boundary, and/or you would end up waiting for useless duplicate network traffic. The fact that on GitHub, such references are visible irrespective of specified repo is not a bug, its a feature. Its the tools (including but not limited to: GitHub Actions) that cause dangerous misunderstanding in appearing to let you specify something they then never actually enforce.

specified: repo location, slightly-difficult-to-preimage hash

intended meaning: use this hash if and only if it is accessible from the default branch of that repo

actual meaning: use this hash. start looking at this location. I do not care whether it is accessible through that location by accident, by intent of merely its uploader, or by explicit and persisting intent of someone with write access to the location.

Because GitHub only cares about AI.

they probably used the publish token in a pull-request-target workflow or something?

What I don't get is how the GitHub Action cache is shared between unprotected and protected refs. Is that really the case?

Why even have protected branch rules when anyone with write access to an unprotected branch can poison the Action cache and compromise the CI on the next protected branch run?

In GitLab CI caches are not shared between unprotected and protected runs.

From a GitHub product owner POV, if the architecture is not to be changed, what is the solution?

A big ugly warning in the UI?

Or, push back on the architecture?

Or, is threatening a big ugly warning in the UI actually pushing back on the architecture?

I take the above back. TanStack messed this up in the way they explicitly cache. This is run from the affected workflow: https://github.com/TanStack/config/blob/main/.github/setup/a...

The restore-key looks too wide and this still looks like an issue. This wide caching may also cause issue if they ever upgrade major nodejs version independently of OS, for example.

Love that feeling when you read through a repo and think, "Wow, this looks cool," and go to star it, and see that you already have, and clearly forgot about it

Anyway, thanks for sharing. It doesn't look like it handles cli auth though (aws, npm, etc. all leave tokens sitting in your home directory). What do you use for those?

Maybe give publishers a way to quarantine versions with a warning that stops the install, but allows users can override if they choose to is the next step?

Give a publisher a way to tag a version as malicious and then in those hours between the exploit being noticed and the package being removed anyone who tries to install gets a message about that version being quarantined and asking whether they want to proceed.

It's not a perfect solution, but I think it's better than just waiting for NPM to take action without opening the door up to another left pad situation.

I think cargo's yank is a good balance. It makes it difficult to pull the yanked version in as a dependency, but doesn't break existing usages, as long as the version is in the lockfile. And I think even then gives you a warning that you are using a yanked package.

The obvious solution is that unpublish should be available within a time window after a new version is published and then unavailable after that.

I mean they brought that incident on themselves...

It would take longer than minutes to validate the claims themselves.

Who vets the sources, and using what scheme?

> had the right idea

Is it no longer the right idea?

No, instead the code that isn't from a dependency is what will cause you to get pwned

The virus fest of the 90s would like a word with you and your C

you can't get infected through the package manager if your language doesn't have a package manager :) turns out C and C++ were playing 4D chess all along

[dead]

Yes, that is clear. But in this particular instance the tanstack packages are downstream of a ton of other packages.

Tanstack infected a bunch of other packages; then resolving their issue doesn’t fix the widespread issue

Maybe gH could, accidentally, 40x for a few minutes globally and eradicate the beast?

Postinstall scripts have remained an effective attack vector for quite a while – which, ironically, has meant the worm's authors had little incentive to try something else, so it was easier to inoculate yourself. Alas, you're right, it should be pretty simple to bypass this kind of protection, if they haven't already (and seems like they have).

Well at runtime one would hope they're not giving their JS app access to their home folder.

The community decided it's too much effort to vet code before publishing it so here we are.

(I'm not being stupid, even ten years ago there were arguments on HN about whether you should audit your dependencies)

I landed on the 'yes, you should know what code you are getting involved with' side.

Cargo is spiritually based on NPM so it's not much better.

Go Get is closer to always locking dependencies unless you explicitly upgrade them with a go get, so it's much much better in my view.

Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go.

In Go projects my policy for upgrading dependencies includes running full AI audit of all code changed across all dependencies, comes out to ~$200 in tokens every time but it gives those warm 'not likely to get pwned' vibes. And it comes with a nice report of likely breaking changes etc.

> Abandon NPM in exchange for what? Cargo? Go get? Pip install?

pnpm, deno, or bun, none of which will run the malicious "prepare" hook in the first place unless specifically allowed.

Distro packages maintained and (hopefully audited on update) by separate maintainers ?

Even linux was subjected to an attack in xz utils. Granted it is much harder and they have a much better auditing problem (something npm should learn from). There really isn't a silver bullet here unfortunately. The industry as a whole needs to get more serious about this.

Exactly, the only real way to escape this madness is if we move back to "Standard Libs" where your project only depends on 1-3 core libraries. For example, .NET and Java are almost entire 'kitchen sink' ecosystems. Arguably for simple projects, Go has a fairly large standard lib.

Just writing the actual code that you are being paid to write

Both Cargo and Go's package manager are a lot better. Can you name comparable security incidents they've had in the last 5 years?

Idk about Python, I refuse to use that language for other reasons.

[dead]

There are npm supply chain exploits in the news every other day. I'm honestly surprised that something as decentralized as Go Modules is more reliable, but here we are. The fact that we're not seeing these stories about e.g. Maven is not at all surprising, given the limited need for third party libraries and the culture of careful upgrades in the Java ecosystem. If npm proponents want the ecosystem to survive, they need to demand / create better and stop making excuses.

Highly recommend using the minimum release age setting, though I think a week is probably overkill. Did any of the recent supply-chain attacks have a malicious version up for more than a day?

Heads up: Your website at en.dev says you're a one-person open source company. That immediately ruled out any of your tools for me and my team; no matter how great they may be, a single developer is a supply chain risk. I wholeheartedly recommend enlarging the team.

What a pleasant surprise to see jdx within comments! I was actually using mise and found aube and decided to publish it on hackernews, I found it really cool!

Though a bit sad that it hadn't received traction back then but I must admit jdx that a lot of the work that you do is really cool.

Also I am happy to know that you are finally able to work on Open source full time, I am glad that I can use open source software created by (in my opinion generous) people like you too, mise is awesome :-D

https://news.ycombinator.com/item?id=48012248

In this case it would have, because the compromised packages were pulled within 3 hours.

There is a “fresh” in there

This confused me too, until I realized that the article is about pnpm, not npm (pnpm reads .npmrc for some reason, despite not having the same options as npm)

On a related note, it seems to be impossible to find the documentation of min-release-age by googling it. Very annoying.

Npm's package-lock.json already handles pinning everything to exact versions, including subdependencies. Pinning exact versions in package.json doesn't affect your subdependencies.

Or help distributions do the manual process of packaging - which involves at least rudimentary security checks - so they can ship newer versions faster.

And then use distro packages.

(I'm not accepting distro fragmentation as counterargument. With containerization the distro is something you can choose. Choose one, help there, and use it everywhere.)

Are you talking about in package.json? What's your threat model? That's what the lock file is for, which also pins transitive dependencies, which is just as crucial. Now what's actually insecure is if you don't commit the lockfile. and if you don't do `npm ci`.

I think `npx` might pull down new versions, too? I wish npm worked more like Elixir where updating the lock file was an explicit command, and everything else used the lock file directly.

its so wild to have seen this advice reverse course over the past year.

it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish.

different times, different threat model I suppose

I've been collecting things you can't pin:

- Python inline dependencies in PEP-0723, which you can pin with a==1.0, but can't be hash-pinned afaik.

- The bin package manager lets you pin binaries, but they aren't hash-pinned either.

- The pants build tool suggests vendoring a get-pants.sh script[0] but it downloads the latest. Even if you pass it a version, it doesn't do any checks on the version number and just installs it to ~/.local/bin

[0]: https://github.com/pantsbuild/setup/blob/gh-pages/get-pants....

The part that always gets me is I tend to only install a few packages like React and maybe some kind of data access layer. But you let that recurse down a few levels and suddenly you've installed a thousand packages, some of them hopelessly obsolete, some of them for patently stupid things that are 1 line of code, etc, etc. I.E. you can't choose to be thoughtful if the main entry points into the language are all built on a pile of garbage.

npm's immaturity is arguably demonstrated by the fact it is always catching up.

Please correct me if I'm wrong but signed packages are still impractical in NPM which is why supply chain attacks still work by editing existing versions or pushing new point releases without a signature.

Or if you put all of the credentials in GitHub actions which is even more trivially exploitable through the actions marketplace because it is just git with a thin proxy, you have an even wider attack vector

--before doesn't save you globally, only min-release-age does, which is in npm since March iirc.

It's a joke that apparently wasn't well received by HN.

React Query is great. I’ve used his router and table component as well. IMO his stuff became popular on merit more than some cargo culting à la redux

Yeah and it’s also ridiculous. They have so many bloated micro-libraries, they have a “headless range” library for controlling ranges and sliders that is marketed as being tiny at only 10kb. And their website is full of glitches and rendering bugs and it takes multiple seconds to navigate pages.

[dead]