2

Recently I am building a web service that user input will be used to run a bash command on the server side. What are the security problem I need to take care?

Right now I find one that user could submit things include pipe like valid thing | something bad and my server did run that something bad! I mainly use nodejs and exec from shelljs to build the server.

1
  • 1
    Please say there is some way you can redefine the problem so that you are not passing any portion of user-provided input directly to a shell. It may also help to give a specific example as it's intended to work in your implementation. Commented Mar 23, 2015 at 3:42

2 Answers 2

6

If you are allowing shell commands to be executed from the browser, then what you are effectively doing is allowing the user to log-in and execute commands on your system as the user that the web-server is running as. Ask yourself if that is what you want to do? The answer is definitely no. No-way. No, not never. In fact, hackers spend a lot of time trying to work out how to do what you have effectively designed in to your system.

You can try and "sanitize" the input, but then all you are doing is asking the hackers to try and find ways around your sanitizer. They are probably smarter than you.

You could try and execute the commands as a user with restricted permissions. Then you are effectively allowing anyone to log-in as that user and execute commands on that system. The UNIX permissions mechanism might protect you a bit.

Finally, you could try using chroot to create a very restricted environment to run your bash commands in. That's quite a lot of work, and there is still the possibility for trojans to be planted in to the restricted environment. If you plan this option, you could look up the makejail command: makejail.

The final option is to not allow users to run arbitrary bash commands, but instead provide a list of preconfigured commands that you allow them to run, which you know are safe.

Also, you may be vulnerable to the Shellshock bug Shellshock

1
  • thank u for your answer. I'd better not create subshell directly and turn to another sulution.
    – qqibrow
    Commented Mar 25, 2015 at 5:36
2

The main thing your enabling that is a problem is your opening your shell to subshells. e.a. just executing a command like /bin/bash would allow an attacker to gain access to your server.

If you really wanna keep running a service like this i would suggest you limit the options the end users (and an attacker) can use, by only allowing commands you know are 'safe' and never execute them directly. Utilize a sub shell indirectly and only after you stripped it of all the dangerous parts. (such as the "|").

Also be wary of misuse by hijacking the connection. SSH does this quite well by utilizing both encryption and session control mechanisms. So hijacking is hard, and most often results in a closed connection. Why reinvent the wheel if there is no need for it ;)

if you do find you need to run commands like this I would recommend you run them through the restricted bash shell. (rsh) it prevents most of those 'bad' things you worry about (but not all)

1
  • thank u for your answer. I'd better not create subshell directly and turn to another sulution.
    – qqibrow
    Commented Mar 25, 2015 at 5:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .