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

41–50 of 138 posts

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

#41

Post by raesene3 »

semi-extrinsic wrote: post #40
raesene3 wrote: post #38

Kind of amusing that this is considered to need a new vuln. report, I kind of assumed it was common knowledge. Most of the programming language package repositories (e.g. npm, rubygems, PyPi, NuGet) have this kind of installation process and limited/no checks for malicious content. Also as there's no consistent use of package signing by the developer (it's either unsupported or not very used) there is also a risk of…

A very insightful look at package signing, and why it wouldn't actually improve security for PyPI, by Python packaging guru Donald Stufft: https://caremad.io/2013/07/packaging-signing-not-holy-grail/

Indeed package signing is not the holy grail and won't solve all problems, but it is a part of a secure system.

For the problem this blog post talks about, I personally think that keybase is the right solution. You can tie a key to a github repository amongst others and then validate that the package you're installing came from the person who put the code on github in the first place...

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

#42

Post by raesene3 »

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…

One of the problems is that npm (and others) put their credentials or some form of API token into dotfiles in the developers home directory, meaning that if you can execute code as the user (via social engineering or malware) you can push new packages.

In some cases it's even accepted practice to put the actual username/password in the clear in a dotfile, which means anyone who can even read a file from the users home directory, can gain persistent access to push packages as them...

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

#43

Post by raesene3 »

chromakode wrote: post #25
spankalee wrote: post #15

Automatically running pre and post scripts is absolutely insane.

Once you've installed a malicious package that you intend to use, you've already lost. Even without a pre/post install script, it'll be executed eventually. The underlying problem is managing risk of the packages you install.

This is very true, but execution at install time (sometimes with root privileges) is a bad idea from a security perspective, especially when it happens with dependencies, which makes it very hard to check all packages that you're installing...

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

#44

Post by mjs »

BenjaminCoe wrote: post #11
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…

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…

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.

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

#46

Post by ambrop7 »

derefr wrote: post #30
wycats wrote: post #20

Earlier quoted context omitted.

All package managers (that I know of) for dynamic languages offer a mechanism for compiling native code for packages that include bindings to C libraries. That mechanism could easily be used to achieve the same goal, even if there was no explicit "post-script" mechanism.

Debian solved this particular problem a long time ago, with pbuilder(1): packages that are installed "from source" simply get compiled in a chroot. Strangely, nobody has ever copied the idea. The modern hipster-language equivalent would probably be to make the package manager depend on the presence of Docker/rkt/systemd, and use it to pull down a dev-env container and build the native bindings in that.

Nix/NixOS - everything is build not only in a chroot, but also in various namespaces. Of course that doesn't help if you actually use a package (directly or indirectly) hence executing it outside of the build chroot.

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

#47

Post by oceanstone »

BenjaminCoe wrote: post #11
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…

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.

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

#48

Post by riffraff »

derefr wrote: post #30
wycats wrote: post #20

Earlier quoted context omitted.

All package managers (that I know of) for dynamic languages offer a mechanism for compiling native code for packages that include bindings to C libraries. That mechanism could easily be used to achieve the same goal, even if there was no explicit "post-script" mechanism.

Debian solved this particular problem a long time ago, with pbuilder(1): packages that are installed "from source" simply get compiled in a chroot. Strangely, nobody has ever copied the idea. The modern hipster-language equivalent would probably be to make the package manager depend on the presence of Docker/rkt/systemd, and use it to pull down a dev-env container and build the native bindings in that.

the problem with relying on chroot is that (AFAIK) it might not be available on all platforms supported by the language-specific package managers.

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

#49

Post by semi-extrinsic »

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.

Firefox has automated "malware checking" for extensions, the Mozilla AMO Validator, and it's been basically torn to pieces by the community for being not actually secure [1] plus a major hassle for developers [2], to the point that large extensions with hundreds of thousands of users have stopped using the official Firefox extensions repository.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1227867#c2

[2] https://forums.zotero.org/discussion/28847/zotero-addon-is-n...

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

#50

Post by raesene3 »

semi-extrinsic wrote: post #49
raesene3 wrote: post #37

Earlier quoted context omitted.

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.

Firefox has automated "malware checking" for extensions, the Mozilla AMO Validator, and it's been basically torn to pieces by the community for being not actually secure [1] plus a major hassle for developers [2], to the point that large extensions with hundreds of thousands of users have stopped using the official Firefox extensions repository. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1227867#c2 [2] https://…

Yep it's a really nasty problem for any package manager that operates at scale.

The problem is that without any centralized validation of packages, it leaves checking to each developer who uses the libraries and obviously from an effort standpoint that just makes it worse (i.e. if it's hard for the repo owner to do validation it's hard x number_of_users for it to be done by end users)

Post reply on HN