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

81–90 of 138 posts

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

#81

Post by Silhouette »

raesene3 wrote: post #37
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…

Unfortunately I don't think that many/any of the Programming language package repositories have manual review processes, or even automated checking for things like known malware... Linux package managers are a different story of course.

Unfortunately I don't think that many/any of the Programming language package repositories have manual review processes, or even automated checking for things like known malware...

It depends on what kind of repository you're trying to build.

If you're talking about something like NPM, PyPI or CPAN, then sure, these are relatively open systems where anyone can contribute but that includes bad people.

An example from the other end of the spectrum would be Boost for C++, which is heavily curated and peer reviewed, good enough in quality that its libraries sometimes become part of the full C++ standard at a later date, and tiny compared to the others I mentioned before.

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

#82

Post by andrewaylett »

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…

Take Maven as an example: it's not vulnerable to this attack for several reasons:

1) No install scripts. Fetching a dependency in NPM will execute arbitrary code. Fetching a dependency in Maven doesn't execute any code from the dependency. Obviously when I run my project, I'm expecting to call code in that dependency, so this is a mitigation not a complete fix. But that does lead on to the next point.

Corollary: You have to change the code in my project to spread the worm, not just add a new dependency, otherwise your worm code won't get executed. This is probably a bit more tricky to get right.

2a) Code deployed internally from CI servers, not local machines. It's got to be code-reviewed before it gets pushed to my employer's package repository.

2b) Code needs to be signed before being uploaded to Maven Central. I'm not going to start typing my GPG key into random unexpected prompts.

Malicious code is still a possibility, but the scope for a worm is much less.

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

#83

Post by TheCoreh »

pygy_ wrote: post #68
kibwen wrote: post #65

Earlier quoted context omitted.

I'm not trying to dispute that a problem exists, only that semver is a red herring here. It seems like the problem that you describe doesn't have to do with semver, rather that it has to do with npm lacking something like lockfiles.

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.

Even if you manually freeze deps to 'x.y.z', the deps of your deps might still be specified with '^'. Ideally you'd shrinkwrap, and commit node_modules to your repo. (In case packages get deleted)

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

#84

Post by jrochkind1 »

davnn wrote: post #56
tatterdemalion wrote: post #52

Earlier quoted context omitted.

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.

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.

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

#85

Post by driverdan »

raesene3 wrote: post #37
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…

Unfortunately I don't think that many/any of the Programming language package repositories have manual review processes, or even automated checking for things like known malware... Linux package managers are a different story of course.

I don't think this is unfortunate at all. I shouldn't have to wait for someone to review my code before publishing an important bugfix. This is the primary thing that drove me away from mobile apps.

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

#86

Post by chromakode »

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 just save + encrypt the original QR code somewhere at the time of scanning it.

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

#87

Post by [deleted] »

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.

[deleted]

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

#88

Post by mortehu »

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…

I would say Debian is not vulnerable (to step 6), even for users of the rolling "unstable" release, since maintainers need to sign package uploads with their PGP key, which is usually protected by a separate password.

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

#89

Post by u223344 »

fibo wrote: post #61

Just to share, there is an issue about uglifyjs https://github.com/mishoo/UglifyJS2/issues/936

Ironically the same person who first reported this npm vulnerability used the wrong package name uglifyjs instead of uglify-js in an unrelated github project.

https://github.com/mishoo/UglifyJS2/issues/936#issuecomment-...

https://github.com/samccone/The-cost-of-transpiling-es2015-i...

Or perhaps was it a security experiment to see how long it took someone to notice.

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

#90

Post by jessaustin »

diegorbaquero wrote: post #14

Now that things like GreenKeeper exists, the ^ should be removed from being a default thing.

Yes, but that should be done in a patch update, so all the semver extremists can ignore the semver violation like they did the first time when "~" was switched to "^": https://github.com/npm/npm/releases/tag/v1.4.3 (note the "3" at the end, instead of "0")
Post reply on HN