Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tinycolor supply chain attack post-mortem

sigh.dev

Post reply on HN
Print view View original

21–30 of 85 posts

Re: Tinycolor supply chain attack post-mortem

#21

Post by skydhash »

STRiDEX wrote: post #11
bikeshaving wrote: post #9

> Local 2FA based publishing isn’t sustainable... Why is local 2FA unsustainable?! The real problem here is automated publishing workflows. The overwhelming majority of NPM packages do not publish often enough or have complicated enough release steps to justify tokens with the power to publish without human intervention. What is so fucking difficult about running `npm publish` manually with 2FA? If maintainers are un…

That's fair, I'm referring to the number of mistakes that happen with local publishing. Publishing the wrong branch, not building from latest etc

So add a wrapper for that, a quick script that checks which branch and revision you are publishing from. The issue here is publishing from a CI you do not control that well and with automated events.

Re: Tinycolor supply chain attack post-mortem

#22

Post by rectang »

Hackbraten wrote: post #19
rectang wrote: post #16

Earlier quoted context omitted.

The conclusion I'm coming to is that depending on packages which only have a single author is problematic. There are too many ways that packages published by one person can be compromised. Packages which don't have approval and review by a reliable third party shouldn't be visible by default in a package manager.

How are you supposed to gain collaborators for a project that no one can possibly find?

There are ways, but at a high level, I don't care. I hate how modern package managers have come to value author convenience over downstream user security.

Re: Tinycolor supply chain attack post-mortem

#23

Post by Terr_ »

tetha wrote: post #6
drdrey wrote: post #2

> A while ago, I collaborated on angulartics2, a shared repository where multiple people still had admin rights. That repo still contained a GitHub Actions secret — a npm token with broad publish rights. This collaborator had access to projects with other people which I believe explains some of the other 40 initial packages that were affected. > A new Shai-Hulud branch was force pushed to angulartics2 with a maliciou…

> But why would an npm token in angulartics2 have publication rights to tinycolor? Imo, this is one of the most classical ways organizations get pwned: That one sin from your youth years ago comes to bite you in the butt. We also had one of these years ago. It wasn't the modern stack everyone was working to scan and optimize and keep us secure that allowed someone to upload stuff to our servers. It was the editor tha…

Thinking of biology, the reason often given for the disappearance of "unused" genes/base-pairs is that there's a metabolic cost to keeping them around and copying them on every cell division, so they vanish from a form of passive attrition.

I wonder if someday we'll find there's also a more active process, which resembles "remove old shit because it may contain security vulnerabilities."

Re: Tinycolor supply chain attack post-mortem

#24

Post by skydhash »

cyberax wrote: post #13

> exfiltrated a npm token with broad publish rights I freaking HATE tokens. I hate them. There should be a better way to do authentication than a glorified static password. An example of how to do it correctly: Github as a token provider for AWS: https://aws.amazon.com/blogs/security/use-iam-roles-to-conne... But this is an exception, rather than a rule.

As another sibling comment have put it, it probably should be short lived or behind a manual verification (passphrase, 2fa,…)

Re: Tinycolor supply chain attack post-mortem

#25

Post by paxys »

STRiDEX wrote: post #11
bikeshaving wrote: post #9

> Local 2FA based publishing isn’t sustainable... Why is local 2FA unsustainable?! The real problem here is automated publishing workflows. The overwhelming majority of NPM packages do not publish often enough or have complicated enough release steps to justify tokens with the power to publish without human intervention. What is so fucking difficult about running `npm publish` manually with 2FA? If maintainers are un…

That's fair, I'm referring to the number of mistakes that happen with local publishing. Publishing the wrong branch, not building from latest etc

You can run the exact same script locally as you do in CI, with the only difference being the addition of a 2FA prompt.

Re: Tinycolor supply chain attack post-mortem

#26

Post by retlehs »

indigodaddy wrote: post #12

Anyone know of a published tool/script to check for the existence of any of the vulnerable npm packages? I don't see anything like that in the stepsecurity page.

This won’t protect against everything, but it still seems like a good idea to implement:

https://github.com/danielroe/provenance-action

Re: Tinycolor supply chain attack post-mortem

#27

Post by tetha »

chatmasta wrote: post #18
cyberax wrote: post #13

> exfiltrated a npm token with broad publish rights I freaking HATE tokens. I hate them. There should be a better way to do authentication than a glorified static password. An example of how to do it correctly: Github as a token provider for AWS: https://aws.amazon.com/blogs/security/use-iam-roles-to-conne... But this is an exception, rather than a rule.

These machine-to-machine OIDC flows seem secure, and maybe they are when they’re implemented properly, but they’re really difficult to configure. And I can’t shake the feeling that they’re basically just “tokens with more moving parts,” at least for a big chunk of exploitation paths. Without a human in the loop, there’s still some “thing” that gets compromised, whether it’s a token or something that generates time-li…

Hence you need to start thinking about threat models and levels of compromise, even in your build system.

If I control the issuing and governance of these short-lived secrets, they very much help against many attacks. Go ahead and extract an upload token for one project which lives for 60 seconds, be my guest. Once I lose control how these tokens are created, most of these advantages go away - you can just create a token every minute, for any project this infrastructure might be responsible for.

If I maintain control about my pipeline definition, I can again do a lot of work to limit damage. For example, if I am in control, I can make sure the stages running untrusted codes have as little access to secrets as possible, and possibly isolate them in bubblewrap, VMs, ..., minimize the code with access to publishing rights. Once I lose control about the pipeline structure, all that goes away. Just add a build step to push all information and secrets to mastodon in individual toots, yey.

To me, this has very much raised questions about keeping pipeline definitions and code in one repository. Or at least, to keep a publishing/release process in there. I don't have a simple solution there, especially for OSS software with little infrastructure - it's not an easy topic. But with these supply chain attacks coming hot and fast every 2 weeks, it's something to think about.

Re: Tinycolor supply chain attack post-mortem

#28

Post by darkamaul »

> That repo still contained a GitHub Actions secret — a npm token with broad publish rights.

One of the advantages of Trusted Publishing [0] is that we no longer need long-lived tokens with publish rights. Instead, tokens are generated on the CI VM and are valid for only 15 minutes.

This has already been implemented in several ecosystems (PyPI, npm, Cargo, Homebrew), and I encourage everyone to use it, it actually makes publishing a bit _easier_.

More importantly, if the documentation around this still feels unclear, don’t hesitate to ask for help. Ecosystem maintainers are usually eager to see wider adoption of this feature.

[0] https://docs.pypi.org/trusted-publishers/

Re: Tinycolor supply chain attack post-mortem

#29

Post by chatmasta »

tetha wrote: post #27
chatmasta wrote: post #18

Earlier quoted context omitted.

These machine-to-machine OIDC flows seem secure, and maybe they are when they’re implemented properly, but they’re really difficult to configure. And I can’t shake the feeling that they’re basically just “tokens with more moving parts,” at least for a big chunk of exploitation paths. Without a human in the loop, there’s still some “thing” that gets compromised, whether it’s a token or something that generates time-li…

Hence you need to start thinking about threat models and levels of compromise, even in your build system. If I control the issuing and governance of these short-lived secrets, they very much help against many attacks. Go ahead and extract an upload token for one project which lives for 60 seconds, be my guest. Once I lose control how these tokens are created, most of these advantages go away - you can just create a t…

But the token wasn’t the primary source of compromise here. It was the GitHub workflow which had the token embedded into it. There was no need for the actor to exfiltrate the token from the workflow to somewhere else, because they could simply run arbitrary code within the workflow.

It would have made little difference if the environment variable was NPM_WEBIDENTITY instead of NPM_TOKEN. The workflow was still compromised.

Re: Tinycolor supply chain attack post-mortem

#30

Post by hinkley »

drdrey wrote: post #2

> A while ago, I collaborated on angulartics2, a shared repository where multiple people still had admin rights. That repo still contained a GitHub Actions secret — a npm token with broad publish rights. This collaborator had access to projects with other people which I believe explains some of the other 40 initial packages that were affected. > A new Shai-Hulud branch was force pushed to angulartics2 with a maliciou…

I have admin rights on someone else’s npm repo and I’ve done most of the recent releases. Becoming admin lit a fire under me to fix all of the annoying things and shitty design decisions that have been stuck in the backlog for years so most of the commits are also mine. I don’t want my name on broken code that “works”.

I had just about convinced myself that we should be using a GitHub action to publish packages because there was always the possibility that publishing directly via 2FA, that one (or specifically I) could fuck up and publish something that wasn’t a snapshot of trunk.

But I worried about stuff like this and procrastinated on forcing the issue with the other admins. And it looks like the universe has again rewarded my procrastination. I don’t know what the answer is but giving your credentials to a third party clearly isn’t it.

Post reply on HN