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

Npm install could be dangerous

github.com

Post reply on HN
Print view View original

91–100 of 100 posts

Re: Npm install could be dangerous

#91

Post by munificent »

moe wrote: post #7

This applies to pretty much every pkg manager ever created. That's why it's important to have end-to-end package signing with a reasonable UI, so people can choose to selectively trust the sources they need and get alerted before new dependencies get pulled in. Sadly I don't know of any pkg manager that implements this correctly.

> This applies to pretty much every pkg manager ever created.

For what it's worth, the package manager for Dart does not have this problem. We specifically didn't add support for any kind of post-install hook because executing arbitrary code from transitive dependencies feels a little fishy to me, and I'm not at all a security person.

Unfortunately, there's lot of good uses for post-install hooks too. It's a hard problem.

Re: Npm install could be dangerous

#92

Post by sprkyco »

schoen wrote: post #65
crazydoggers wrote: post #23

Earlier quoted context omitted.

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"

A lot of people using package managers, though, might think that someone else has read the code that's about to be installed (so they don't have to read it before installing it). I've installed five or six things for development work using pip recently and I would have been shocked if they were malicious (or if I had to read thousands of lines of Python to make sure they weren't malicious).

It is interesting the contrast in cultures between developers and "hackers" it was not uncommon to hear about script kiddies picking up code and realizing later that a rm rf line was contained in the file. The common reaction to a scenario like that would be well the script kid got what he deserved. However, there is a fringe within that group that is more interested in testing these thing in VMs (so the damage would be minimal in that case). However when a security issue is brought to light like this and the only difference is the intentions of the user the arguments are so completely different. Script Kid downloads rm rf script and runs HAHA! Javascript Developer downloads package and runs blindly "well who let that happen and how do we stop it from happening again" hopefully some HN reader can respond to this to succinctly convey the philosophical mechanism going on here as I cannot quite place it.

Re: Npm install could be dangerous

#93

Post by eyko »

namuol wrote: post #72
eyko wrote: post #61

Earlier quoted context omitted.

Unix user permissions take care of that.

Kinda. It would be nicer to limit permissions on a per-"application" level, requiring one-time explicit grants from the user, kinda like how a lot of platforms already do it (web browsers, Android APK, etc).

> It would be nicer to limit permissions on a per-"application" level, requiring one-time explicit grants from the user

Most services run under their own username/group for exactly this reason. A user should only be able to obliterate their `$HOME` folder and nothing else, and if you run npm as a certain user, you can restrict that even further by setting the right permissions. If you still need further protection from accidental deletions, it's probably a good idea to use a filesystem with snapshot support like ZFS or BTRFS.

Very few programs should be run as root, and developers should know this. Random scripts pulled from the internet are not in that list. If you absolutely need to be logged in as root, then it's probably best you run npm as a different user (runuser -l username -c command). I cannot imagine any reason why you would need to run `npm install` as root. Global packages? Perhaps users should chmod their global npm modules folder to allow installing as an unprivileged user, or at least as the npm user, and then run npm as that user. My global npm packages folder is owned by the npm user/group and if I need to install a global npm package, i usually run it as `runuser -l npm -c npm install -g ...` (or sudo -u npm on osx). It's not an extreme precaution and it's not even a hassle, and while I understand it's not the default, it's also not true that by default npm install can write or delete files outside of your home folder (unless run as root)

I'm not sure the title of this should be "npm install could be dangerous" more than "running scripts as root could be very dangerous", which is a no-brainer. The rule of thumb for users/admins in unix-like systems is to keep permissions as strict as possible.

Re: Npm install could be dangerous

#95

Post by colechristensen »

sigzero wrote: post #5
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".

Rust/Cargo, homebrew, probably a host of others.

homebrew is at least curated and every time you update you see several packages removed

Re: Npm install could be dangerous

#96

Post by schoen »

sprkyco wrote: post #92
schoen wrote: post #65

Earlier quoted context omitted.

A lot of people using package managers, though, might think that someone else has read the code that's about to be installed (so they don't have to read it before installing it). I've installed five or six things for development work using pip recently and I would have been shocked if they were malicious (or if I had to read thousands of lines of Python to make sure they weren't malicious).

It is interesting the contrast in cultures between developers and "hackers" it was not uncommon to hear about script kiddies picking up code and realizing later that a rm rf line was contained in the file. The common reaction to a scenario like that would be well the script kid got what he deserved. However, there is a fringe within that group that is more interested in testing these thing in VMs (so the damage would…

Maybe the script kids think that they're playing One-Shot Prisoner's Dilemma (or occasionally Iterated Prisoner's Dilemma) and the developers think they're playing some other game?

Re: Npm install could be dangerous

#97

Post by XorNot »

eyko wrote: post #93
namuol wrote: post #72

Earlier quoted context omitted.

Kinda. It would be nicer to limit permissions on a per-"application" level, requiring one-time explicit grants from the user, kinda like how a lot of platforms already do it (web browsers, Android APK, etc).

> It would be nicer to limit permissions on a per-"application" level, requiring one-time explicit grants from the user Most services run under their own username/group for exactly this reason. A user should only be able to obliterate their `$HOME` folder and nothing else, and if you run npm as a certain user, you can restrict that even further by setting the right permissions. If you still need further protection fr…

The problem is this doesn't tally well with the overall user experience.

I don't want my hard drive being littered with files owned by not-me, because they don't work properly when I need to rsync things and I can't change their ownership easily etc.

What I want is a kind of "sub-user": where I have sudo like powers over files owned by my user account by default, which are then dropped for individual commands - or something similar.

Which comes back to my original point: we've lots of mechanisms, but none of them actually wrap-well or seamlessly with how you actually work which makes them too much of a pain to use for the 99% of the time when everything is fine.

Re: Npm install could be dangerous

#98

Post by sprkyco »

schoen wrote: post #96
sprkyco wrote: post #92

Earlier quoted context omitted.

It is interesting the contrast in cultures between developers and "hackers" it was not uncommon to hear about script kiddies picking up code and realizing later that a rm rf line was contained in the file. The common reaction to a scenario like that would be well the script kid got what he deserved. However, there is a fringe within that group that is more interested in testing these thing in VMs (so the damage would…

Maybe the script kids think that they're playing One-Shot Prisoner's Dilemma (or occasionally Iterated Prisoner's Dilemma) and the developers think they're playing some other game?

Thanks for the reference schoen this is why I love HN. I sometimes have difficulty organizing thoughts into neatly categorized theories like this, best I can usually do is realize i'm sure somebody has thought about this before and explained better than I can.

Re: Npm install could be dangerous

#99

Post by attilagyorffy »

mahouse wrote: post #47
attilagyorffy wrote: post #35

This is exactly why i think modern kernel level security layers, such as FreeBSD jails (or Docker/LXC) were born. Provided your app runs within a jail, it wouldn't matter much anymore: > Once inside the jail, a process is not permitted to escape outside of this subtree You could also develop within isolation, therefore your development env would be safer and even similar to a production environment. Needless to say,…

I always develop inside a virtual machine, with a shared folder in between so I can write code on the host, but everything runs in the guest.

That's also a good solution I think. One of the main advantages of using containers though is real portability. This means in theory you could just push your container in development into production without too much hassle and making administrators nervous :) That's not the same level of portability a full VM would give you.

Admittedly this is more of a discussion about containers and security than npm itself but I'm interested in discovering the options out there. I may attempt to move all my stuff to containers for a bit and write about my findings.

Re: Npm install could be dangerous

#100

Post by chairfield »

ffn wrote: post #34

Just another reason to install nodejs with a node versioning machine like nvm or n... or to chown your /usr dir so you don't have to run sudo every time you want to npm install. Since you need super user privileges to accidentally remove your system on most linux distros, it really helps if you don't form the habit of sudo npm installing everything.

Which will unfortunately prevent yourself from running sudo in the future, at least on Ubuntu. /usr/bin/sudo must be owned by uid 0.
Post reply on HN