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

Vulnerability #319816 – npm fails to restrict the actions of malicious packages

kb.cert.org

Post reply on HN
Print view View original

121–130 of 138 posts

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#121

Post by kiallmacinnes »

kvz wrote: post #51
oceanstone wrote: post #47

Earlier quoted context omitted.

Looking forward to 2-factor authentication in npm! For what it's worth, I find Google Authenticator offers a user better experience than text message based MFA.

Until you lose your phone. There is no way to back up/recover. So it's tied to this particular device forever. This has been reported years ago and never fixed. Use authy or sms.

On a personal note, I despise apps like Authy. Every site I've tried to use 2FA on, which didn't use the standard HOTP/TOTP/U2F used an entirely different proprietary app. I have zero interest in having multiple 2FA apps, and even less interest in remembering which app I used on which site. While this clearly isn't Authys fault, its nevertheless a problem.

In other words, please just use standards based 2FA - or SMS/Phone calls.

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#122

Post by kiallmacinnes »

NetStrikeForce wrote: post #53
kvz wrote: post #51

Earlier quoted context omitted.

Until you lose your phone. There is no way to back up/recover. So it's tied to this particular device forever. This has been reported years ago and never fixed. Use authy or sms.

I don't think that's accurate. I've changed phones multiple times and the worst I had to do was find my list of 10 recovery passwords to use one to get in and change the phone I use with Authenticator. Usually I would just login and add the new phone.

Agree, I've lost phones with many of my 2FA tokens on it, I pulled out my backup codes and got back into all 10-15 or so sites which I use 2FA on.

With the exception of a SMS to a registered phone recovery method, if I can loose my 2FA token, and loose my backup codes, and still access my account, then the 2FA implementation is IMO deeply flawed.

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#123

Post by [deleted] »

NetStrikeForce wrote: post #53
kvz wrote: post #51

Earlier quoted context omitted.

Until you lose your phone. There is no way to back up/recover. So it's tied to this particular device forever. This has been reported years ago and never fixed. Use authy or sms.

I don't think that's accurate. I've changed phones multiple times and the worst I had to do was find my list of 10 recovery passwords to use one to get in and change the phone I use with Authenticator. Usually I would just login and add the new phone.

[deleted]

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#124

Post by matt_kantor »

jrochkind1 wrote: post #84
davnn wrote: post #56

Earlier quoted context omitted.

Everyone does and I don't think we will be able to change that. It would be nice if there would be a tool that would allow developers to mark a new release as safe. Every package would have it's social safety score and you could decide if you want to investigate a release further.

What do you mean by 'safe'? There is such a tool built-into semver -- it's releasing with a patch or minor version bump! Which means it should be entirely backwards compatible with the previous release. Do you mean something else by 'safe'? I think the issue parent is worried about is if you can't trust the author's declaration of safety.

I think davnn meant a voting mechanism to allow other devs (besides the package's publisher) to vouch for its safety.

At least that's how I interpreted "social safety score".

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#125

Post by insin »

jonahx wrote: post #108
pygy_ wrote: post #68

Earlier quoted context omitted.

It is semver compounded with the "^x.y.z" version requirements for dependencies that NPM uses as a default when a package author `npm install --save` something. When someone else installs that package it will bump y or z if `x > 0`, and z if `x == 0 && y > 0` for all dependencies. You can manually freeze deps to 'x.y.z'. The main problem is the "^" default.

what is the recommended way to globally change that default?

    npm config set save-exact true

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#126

Post by matt_kantor »

_asummers wrote: post #94
mjs wrote: post #44

Earlier quoted context omitted.

On update, can you send email to the purported author, telling them they've updated the package? (Similar to those "you have logged into some site from a new computer" emails.) An easy way to undo a publish would also be useful.

Totally about your first suggestion. But just a reminder, this whole look into NPM began because someone deleted his published packages. Don't know if that's something we should be adding. Deleting versions to me sounds like rebasing public git history.

How about a delay before making the package publicly available so that there could be an undo window? I'm not sure what an appropriate duration would be, as there are obviously situations where someone might want to publish an urgent bugfix quickly.

This could also save publishers from their own "whoops" moments, akin to gmail's super-handy "undo send" feature[1].

[1]: https://support.google.com/mail/answer/1284885?hl=en

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#127

Post by insin »

msoad wrote: post #17
spankalee wrote: post #15

Automatically running pre and post scripts is absolutely insane.

Yes, with that you don't even need to "socially fool the package owner". You can use common misspelling for famous packages. It gets you very far. For example "lowdash" instead of lodash.

I wonder if npm has metrics for this - how many times a month are people attempting to "npm install boostrap"?

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#128

Post by davnn »

matt_kantor wrote: post #124
jrochkind1 wrote: post #84

Earlier quoted context omitted.

What do you mean by 'safe'? There is such a tool built-into semver -- it's releasing with a patch or minor version bump! Which means it should be entirely backwards compatible with the previous release. Do you mean something else by 'safe'? I think the issue parent is worried about is if you can't trust the author's declaration of safety.

I think davnn meant a voting mechanism to allow other devs (besides the package's publisher) to vouch for its safety. At least that's how I interpreted "social safety score".

Exactly!

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#129

Post by nailer »

u223344 wrote: post #91
nailer wrote: post #62

Earlier quoted context omitted.

The uglify authors should use 'uglify' per the naming conventions and can easily reserve uglify-js and uglifyjs as empty / legacy packages.

According to the parent link they've been waiting for npm support to respond for a over a month.

They filed an official dispute 11 hours ago.

Re: Vulnerability #319816 – npm fails to restrict the actions of malicious packages

#130

Post by semi-extrinsic »

raesene3 wrote: post #104
semi-extrinsic wrote: post #101

Earlier quoted context omitted.

The problem is basically how the centralized validation is supposed to work. For e.g. the Linux kernel, it's doable because all code in the kernel must (almost by definition) interact with some other part of the kernel. Thus someone else than the code owner, being responsible for those other parts of the kernel, can be tasked with signing off on the new code being good and non-malicious. But for NPM or PyPI, where an…

Well if there's no central validation, that leaves all individual users to validate packages before use (which is a huge amount of work)... The problem is that companies are using these packages as though they are trusted (i.e. not validating them when using them), and that's part of the value proposition in the first place (i.e. it's easier to use this package than write it myself), but it's missing the cost of vali…

I completely agree on the first two paragraphs.

Wrt. signing: I'm assuming we are talking about PyPI and NPM here. Also I'm assuming the major threat vector for a repository compromise is that (some of) the dev's accounts on some other services (most likely email) are somehow compromised. In which case it's down to that dev's OPSEC practices whether the repository can be compromised using the data from $OTHER_SERVICE. If the dev has poor OPSEC and would reuse the password for multiple accounts in a user/pass repo auth scenario, it's reasonable that this person would also have emailed themself the keys for signing packages, e.g. for transferring to another location behind a firewall. In either case, you're down to trusting the dev's OPSEC.

IMO, the threat models for other kinds of compromises which signing protects against are much more far fetched. AFAICT neither PyPI nor NPM use third-party mirrors, which basically leaves MitM attacks. If an attacker is capable of successfully MitM-ing the connections you make to PyPI/NPM over https, you have much bigger problems.

Or am I missing your point here?

Post reply on HN