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

31–40 of 85 posts

Re: Tinycolor supply chain attack post-mortem

#31

Post by cyberax »

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…

Universal OIDC tokens would slow down the lateral expansion and make it more difficult.

You won't be able to exfiltrate a token that allows you to publish an NPM package outside of a workflow, the infection has to happen during a build on GH.

Re: Tinycolor supply chain attack post-mortem

#32

Post by mnahkies »

I think the point around incorporating MFA into the automated publishing flow isn't getting enough attention.

I've got no problem with doing an MFA prompt to confirm publish by a CI workflow - but last I looked this was a convoluted process of opening a https tunnel out (using a third party solution) such that you could provide the code.

I'd love to see either npm or GitHub provide an easy, out the box way, for me to provide/confirm a code during CI.

Re: Tinycolor supply chain attack post-mortem

#33

Post by KronisLV »

tcoff91 wrote: post #7
rectang wrote: post #4

Two-factor auth for publishing is helpful, but requiring cryptographically signed approval by multiple authors would be more helpful. Then compromising a single author wouldn't be enough.

Many packages have only 1 author.

I'm not sure why we never got around to more human in the loop with 2FA when it comes to this sort of stuff: "Oh, you want to publish a new package? Okay, confirm it on this app on your device/phone to make sure." Surely a button press on a pre-approved device wouldn't be too hard, pretty much how every user initiated online banking payment over here goes like.

I once heard from a sysadmin that didn't want to automate certificate renewal and other things, because he believed that doing so would take away useful skills or some inner knowledge of how the system works. Because of the human error risk, I thought that was stupid, but when it comes to approval processes, I think it makes sense. Especially because pushing code doesn't necessarily mean the same thing as such an approval, or the main device that you push code from could also get compromised, using your phone as 2FA could save you.

Then again, maybe I'm also stupid and the way we build our software is messed up on a fundamental level with all of the dependencies and nobody being able to practically audit all of the code they import, given deadlines, limited skills and resources and so on. Maybe it's all just fighting against a windmill.

Re: Tinycolor supply chain attack post-mortem

#34

Post by STRiDEX »

paxys wrote: post #25
STRiDEX wrote: post #11

Earlier quoted context omitted.

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.

That's a good point, I would lose package provenance that way. I guess that is fine since it didn't prevent anything here.

I can look into that.

Re: Tinycolor supply chain attack post-mortem

#35

Post by Hackbraten »

rectang wrote: post #22
Hackbraten wrote: post #19

Earlier quoted context omitted.

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.

Fair enough.

In the meantime, I'm trying to do my part through occasional random spot inspections when there's an update to a package, and encourage others to do the same for swarm coverage.

Re: Tinycolor supply chain attack post-mortem

#36

Post by indigodaddy »

retlehs wrote: post #26
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

Yep I did see that, but I'm not planning on pushing anything, just want a tool to scan for any of the offending packages. Could make my own but feel like somebody must have already made something (and probably better than I can)

Re: Tinycolor supply chain attack post-mortem

#37

Post by tcoff91 »

mnahkies wrote: post #32

I think the point around incorporating MFA into the automated publishing flow isn't getting enough attention. I've got no problem with doing an MFA prompt to confirm publish by a CI workflow - but last I looked this was a convoluted process of opening a https tunnel out (using a third party solution) such that you could provide the code. I'd love to see either npm or GitHub provide an easy, out the box way, for me to…

Publishing a package involves 2 phases: uploading the package to npmjs, and making it availble to users. Right now these 2 phases are bundled together into 1 operation.

I think the right way to approach this is to unbundle uploading the packages & publishing packages so that they're available to end-users.

CI systems should be able to build & upload packages in a fully automated manner.

Publishing the uploaded packages should require a human to log into npmjs's website & manually publish the package and go through MFA.

Re: Tinycolor supply chain attack post-mortem

#38

Post by x0x0 »

rectang wrote: post #16
tcoff91 wrote: post #7

Earlier quoted context omitted.

Many packages have only 1 author.

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.

That's a lot of entitlement for things you haven't paid a cent for; not just multiple authors but trusted 3rd parties; approval and review; etc.

Re: Tinycolor supply chain attack post-mortem

#40

Post by rectang »

x0x0 wrote: post #38
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.

That's a lot of entitlement for things you haven't paid a cent for; not just multiple authors but trusted 3rd parties; approval and review; etc.

I’ve done all those things myself (past ASF member where all that and more was SOP), so I realize what I’m asking for. It’s not crazy for authors of small packages to form small collectives and serve as each others’ trusted third parties.

In any case, if the choice is “frequent supply chain compromise, take it or leave it”, the answer is of course “leave it”.

If we need to pay for curated packages because the problems with NPM are endemic, that’s not unreasonable.

Post reply on HN