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

Post Mortem: axios NPM supply chain compromise

github.com

Post reply on HN
Print view View original

81–90 of 165 posts

Re: Post Mortem: axios NPM supply chain compromise

#81

Post by lrvick »

charcircuit wrote: post #38
lrvick wrote: post #32

Earlier quoted context omitted.

To prevent supply chain attacks you need multi party cryptographic attestation at every layer, which is pretty straight forward, but you are correct, NPM and GitHub controls absolutely will not save you. Microsoft insists their centralized approach can work, but we have plenty of evidence it does not. Operate under the assumption all accounts will be taken over because centralized corporate auth systems are fundament…

And for 5 there should be help on the NPM end to make it so that the alarms can fire before the new update is actually revealed to the public. There could be a short staging time where it could be revoked before any harm has been done. During this staging time NPM should also scan the package through a malware scanner before allowing it to go public.

I agree that would be nice, but NPM absolutely will not do any basic supply chain integrity work. They are actively opposed to it citing concerns that it might turn off lower skill developers that would be too annoyed by tapping a yubikey to sign releases or code. I have talked to them enough times over the years to have completely given up here.

Whats even more stupid is they actually started mandating 2FA for high risk packages, and FIDO2 supports being used to actually sign artifacts, but they instead simply use it for auth, and let releases stay unsigned. Even the developers they insisted hold cryptographic signing keys, they insist on only throw-away signatures for auth, but not using them for artifact signing to prevent impersonation. It is golf clap level stupid.

Consider them a CDN that wants to analyze your code for AI training for their employer and nothing more. Any security controls that might restrict the flow of publishing even a little bit will be rejected.

Re: Post Mortem: axios NPM supply chain compromise

#82

Post by lrvick »

4ndrewl wrote: post #57
lrvick wrote: post #24

Earlier quoted context omitted.

Anyone that maintains code for others to consume has a basic obligation to do the bare minimum to make sure their reputations are not hijacked by bad actors. Just sign commits and reviews. It is so easy to stop these attacks that not doing so is like a doctor that refuses to wash their hands between patients. If you are not going to wash your hands do not be a doctor. If you are not going to sign your code do not be…

No they don't! They have literally no obligations to you - and you've got the MIT/APL/GPL license to prove it. You're getting the benefit of their labour for free! Even if they did sign the code, What's stopping them slipping some crypto link in. And do they also need to check all the transitive depdencies in their code?

They have basic obligations as highly trusted FOSS software maintainers, a role they allowed themselves to be elected into, to make sure their hard earned goodwill and trust is not stolen by a bad actor. They also have a basic obligation to make sure they have accountability and review of all code before it gets to their users.

Sitting back and expecting Microsoft to keep the community safe is going to continue to end badly. The community has an obligation to each other.

Like, no one is making someone go bring a bunch of food to feed the homeless, but if you do, you have some basic social obligation to make sure it is sanitary and not poison.

People who give things away for free widely absolutely have obligations, and if they do not like those, they should hand off the project to a quorum of responsible maintainers and demote themselves to just a contributor.

Re: Post Mortem: axios NPM supply chain compromise

#83

Post by lrvick »

hahn-kev wrote: post #48
lrvick wrote: post #24

Earlier quoted context omitted.

Anyone that maintains code for others to consume has a basic obligation to do the bare minimum to make sure their reputations are not hijacked by bad actors. Just sign commits and reviews. It is so easy to stop these attacks that not doing so is like a doctor that refuses to wash their hands between patients. If you are not going to wash your hands do not be a doctor. If you are not going to sign your code do not be…

If you're paid then sure. Otherwise... It depends.

Is a doctor doing volunteer work still obligated to wash their hands between patients?

Is a food pantry giving away free food obligated to check expiration dates and make sure the food is properly sealed?

Volunteer work absolutely has obligations, and I do not know why software volunteers are exempt from any responsibility unless they are being paid.

If you do not want to do the volunteer work in a safe way, please hand off the job to a volunteer willing to do so.

Re: Post Mortem: axios NPM supply chain compromise

#84

Post by lrvick »

eviks wrote: post #67
lrvick wrote: post #18

I ask this on every supply chain security fail: Can we please mandate signing packages? Or at least commits? NPM rejected PRs to support optional signing multiple times more than a decade ago now, and this choice has not aged well. Anyone that cannot take 5 minutes to set up commit signing with a $40 usb smartcard to prevent impersonation has absolutely no business writing widely depended upon FOSS software. Normaliz…

"Anyone that cannot spend $40+ to give every FOSS maintainer a smartcard and maybe even separate machines for releases and make the more secure workflow truly 5 minutes has absolutely no business widely depending upon FOSS"

A $50 used laptop from goodwill and a $40 yubikey will do the job.

If maintainers really cannot afford that, they should flag it as a major big bold print supply chain risk on the readme: "We cannot afford 4 yubikeys for our maintainers and thus all code is signed with software keys in virtual machines as a best effort defense. Donate to our fund [here] to raise $500 for dedicated release hardware"

Friends and I have gotten 100s of yubikeys and nitrokeys donated to FOSS maintainers, but FOSS maintainers have to be willing to say they would use them and signal that they need them.

Honestly though, anyone that cannot afford $40 I expect is at high risk of being bribed or having to give up contributing to take on more work, so we should significantly fund any project signaling that much desperation.

Re: Post Mortem: axios NPM supply chain compromise

#85

Post by [deleted] »

pas wrote: post #59
dns_snek wrote: post #50

Earlier quoted context omitted.

What you sign or don't sign in your Git repo doesn't matter because NPM doesn't publish from a Git repo. Signing commits is still useful for your contributors and downstream forks but it won't have any effect on the users who use your package via NPM. I think NPM is fully to blame here. Packages that exceed a certain level of popularity should require signing/strong 2FA. They should implement more schemes that publis…

2FA was mandated by npm they had 2FA, but likely software TOTP (so it was either autofilled via 1password (or similar), or they were able to steal the seed) at this point I think publishing an npm app and asking people to scan a QR with it is the easiest way (so people don't end up with 1 actual factor)

[deleted]

Re: Post Mortem: axios NPM supply chain compromise

#86

Post by lrvick »

pas wrote: post #59
dns_snek wrote: post #50

Earlier quoted context omitted.

What you sign or don't sign in your Git repo doesn't matter because NPM doesn't publish from a Git repo. Signing commits is still useful for your contributors and downstream forks but it won't have any effect on the users who use your package via NPM. I think NPM is fully to blame here. Packages that exceed a certain level of popularity should require signing/strong 2FA. They should implement more schemes that publis…

2FA was mandated by npm they had 2FA, but likely software TOTP (so it was either autofilled via 1password (or similar), or they were able to steal the seed) at this point I think publishing an npm app and asking people to scan a QR with it is the easiest way (so people don't end up with 1 actual factor)

What they need to mandate is hardware anchored passkeys/fido2/webauthn for both auth and package signing, with the -option- to sign with PGP for those that have well trusted PGP keys.

They won't do this, I have talked to them plenty of times about it. But, if they did, the supply chain attacks would almost entirely stop.

Re: Post Mortem: axios NPM supply chain compromise

#87

Post by momo_dev »

minitech wrote: post #54
momo_dev wrote: post #51

this is why i pin every dependency hash in my python projects. pip install --require-hashes with a locked requirements file catches exactly this, if the package hash changes unexpectedly the install fails. surprised this isn't the default in the npm ecosystem

Npm and the other JavaScript package managers do generate and check lockfiles with hashes by default. This was a new release, not a republishing of an old version (which isn’t possible on the npm registry anyway).

i wasn't aware npm lockfiles check hashes by default now. my concern is more about the initial install before a lockfile exists, like in CI from a fresh clone without a committed lockfile. but you're right, once the lockfile is there the hash mismatch would be caught.

Re: Post Mortem: axios NPM supply chain compromise

#88

Post by 4ndrewl »

lrvick wrote: post #82
4ndrewl wrote: post #57

Earlier quoted context omitted.

No they don't! They have literally no obligations to you - and you've got the MIT/APL/GPL license to prove it. You're getting the benefit of their labour for free! Even if they did sign the code, What's stopping them slipping some crypto link in. And do they also need to check all the transitive depdencies in their code?

They have basic obligations as highly trusted FOSS software maintainers, a role they allowed themselves to be elected into, to make sure their hard earned goodwill and trust is not stolen by a bad actor. They also have a basic obligation to make sure they have accountability and review of all code before it gets to their users. Sitting back and expecting Microsoft to keep the community safe is going to continue to en…

They literally owe you nothing. They can walk away tomorrow, sell their github account, introduce breaking changes, add bugs, die, add crypto links, whatever.

>if they do not like those, they should hand off the project to a quoarum of >responsible maintainers and demote themselves to just a contributor.

The most responsible thing to do is to release it under an OSS license and let whoever, yes - including you, fork and maintain their own copy if it's that important.

Re: Post Mortem: axios NPM supply chain compromise

#89

Post by lrvick »

HumanOstrich wrote: post #78
pas wrote: post #59

Earlier quoted context omitted.

2FA was mandated by npm they had 2FA, but likely software TOTP (so it was either autofilled via 1password (or similar), or they were able to steal the seed) at this point I think publishing an npm app and asking people to scan a QR with it is the easiest way (so people don't end up with 1 actual factor)

So you think the answer is replacing a requirement for a 6-digit 2FA code that can be typed into the npm publishing CLI with a requirement for a device that has a camera that can scan a QR code and then... what? What does the QR code do on the device? How does the npm CLI present the QR code?

Simply supporting passkeys gives people domain locked login via qr/phone, or any fido2 usb device. No more keyboard entry required for login other than username, which means phishing is off the table. Standards are great if we can get anyone to use them.

Re: Post Mortem: axios NPM supply chain compromise

#90

Post by lrvick »

Zopieux wrote: post #73
lrvick wrote: post #22

Earlier quoted context omitted.

An owner being compromised is absolutely survivable on a responsibly run FOSS project with proper commit/review/push signing. This and every other recent supply chain attack was completely preventable. So much so I am very comfortable victim blaming at this point. This is absolutely on the Axios team. Go setup some smartcards for signing git push/commit and publish those keys widely, and mandate signed merge commits…

This only works up to a point. Some human needs some way of changing the publication setup in case something goes wrong or changes. What you're asking is blowing a proverbial e-fuse once the setup is known to be working. This is software, shit will go wrong at some point and you need a way to make changes.

Of course, which is why all the (decent) tooling for this is provider agnostic, and provides documentation for multi-party-sharded backups so a quorum of maintainers can always re-assemble the key by hand for any reason if needed.
Post reply on HN