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

51–60 of 138 posts

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

#51

Post by kvz »

oceanstone wrote: post #47
BenjaminCoe wrote: post #11

Earlier quoted context omitted.

Similar problems exist in most package management systems. registries that have a manual review process mitigate this danger, but there's still always a risk of malicious code getting into the world. Having said this, we'd like to make exploits such as those discussed in #319816 as difficult as possible. We're exploring supporting new authentication strategies: such as 2-factor authentication, SAML, and asymmetric ke…

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.

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

#52

Post by tatterdemalion »

kibwen wrote: post #34

> npm encourages the use of semver, or semantic > versioning. With semver, dependencies are not locked to > a certain version by default. For any dependency of a > package, the dependency author can push a new version of > the package. I don't see how this has anything to do with semver. Semver doesn't say anything about not locking dependencies to a certain version (i.e., locking to a specific version is totally leg…

I think that semver encourages unaudited updates by acting as a substitute for auditing in practice. Obviously the spec doesn't say that you should blindly accept all bugfix updates, but in practice many people do. I often do.

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

#53

Post by NetStrikeForce »

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.

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.

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

#54

Post by vbezhenar »

blaisio wrote: post #8

Unless I'm not understanding this correctly, every package manager is vulnerable to this attack (along with many others). I'm not sure why someone bothered to write this down and make an official "disclosure". Maybe someone more knowledgeable can explain? I mean really the idea is just that if someone got somebody else's password, they could use it to trick other people into installing a program. Even email has this…

If I use maven, dependencies are plain JAR files. Adding dependency doesn't do anything but simple file manipulations. To affect build process, maven uses distinct kind of dependency called plugins.

Actually I'm surprised that npm uses some kind of scripts. All I want is to download some JS files. Why is there any scripts at all? I guess it's needed for native compilation, but it's a lazy solution, there could be better solutions.

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

#56

Post by davnn »

tatterdemalion wrote: post #52
kibwen wrote: post #34

> npm encourages the use of semver, or semantic > versioning. With semver, dependencies are not locked to > a certain version by default. For any dependency of a > package, the dependency author can push a new version of > the package. I don't see how this has anything to do with semver. Semver doesn't say anything about not locking dependencies to a certain version (i.e., locking to a specific version is totally leg…

I think that semver encourages unaudited updates by acting as a substitute for auditing in practice. Obviously the spec doesn't say that you should blindly accept all bugfix updates, but in practice many people do. I often do.

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.

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

#57

Post by inglor »

kibwen wrote: post #34

> npm encourages the use of semver, or semantic > versioning. With semver, dependencies are not locked to > a certain version by default. For any dependency of a > package, the dependency author can push a new version of > the package. I don't see how this has anything to do with semver. Semver doesn't say anything about not locking dependencies to a certain version (i.e., locking to a specific version is totally leg…

When you `npm install` a package by default when other users `npm install` it it will install the most recent patch version - even if it's different from the one you installed. So if you install dependencies through `npm install --save` which is the default and advertized way - you can get completely different code between production and staging.

As a library maintainer, patches breaking the library is something that happens (not often, but still) - testing can eliminate a lot but not all bugs.

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

#59

Post by inglor »

It's disappointing to see you post this Sebastian, sure - Babel was affected by the whole left-pad ordeal but is more drama what would really help right now?

You're a doer - if you want to see something done about it at Facebook no one is stopping you from forking NPM or contributing code to it.

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

#60

Post by davnn »

mkagenius wrote: post #3
ktRolster wrote: post #2

And no intention from NPM to fix (according to the article)

What solution can we propose?

I've already written it in another comment: a different way of solving the problem would be to build a tool that allows developers to mark releases as safe. (public lgtm) Every package would have a safety score and you could decide yourself if that's good enough for you.
Post reply on HN