Can the `system` function pose severe security threats on a shared hosting server?

Question

I recently bought an account from a shared hosting company and I needed the php system function to be enabled for one of my projects.
So I created a ticket and asked them to enable it. This is what they responded:

Enabling the system function poses severe security threats on the entire server. Thus it can not be enabled.

Now I have this question. Are they right? Can I somehow do any harm through the use of functions like system, exec, pssthru etc. ?
The OS is Linux.

Answer 1

The PHP system call simply relays commands to the command line of the OS. If you don't have command line access to the server you're renting, then you can see the obvious concern with allowing that command, as now you as a developer have access to the command prompt.

However, even if you do have command line access, incorporating the 'system' call into PHP code can do even more damage, as it exposes the command line to any insecurities your web application may have. Suppose I'm able to carry out an injection or XSS attack on your web application - if I can successfully carry out such an exploit, the probability that I can send commands directly to your web server is extremely high. Once I'm there, I have entirely compromised your individual web server.

So, in a nut shell, yes, the system call can be incredibly insecure without properly sanitized inputs.

Answer 2

Another issue with system calls in a shared hosting environment is that the PHP processor (apache/mod_php) is likely run by a user with different/more permissions than your account (e.g., it can bind listen to incoming TCP messages on port 80, read files of every shared host user).

When you log in to shared hosting and have command line access you are a minimally privileged user (only edit your own files; and start/stop your apache MPM workers). So one could potentially use system called from php as a form of privilege escalation (to say eavesdrop on other users on the shared hosting).

Additionally, its an insecure practice to use eval/system calls in secure programs, especially when the command to eval/system is constructed from string processing which is easily injectible. For example, you could have a command eval("mkdir $user_input");, but an attacker could change $user_input="blank; rm -rf *" which could possibly delete some important files. The calls exist to make life simpler when security is a non-issue (e.g., its a local script run by you on your own comptuer only).

There is almost always a better way to accomplish the same task. Maybe your language has a custom commands that only can run specific system calls; e.g., python has os.mkdir (I'm not familiar with PHP). Or maybe the language has a safer form of eval that doesn't have an injectable form (analogous to how bound parameters defeat SQL injection). For example, python has subprocess where subprocess.call(['mkdir', new_dir_name]) is not susceptible to shell injection (even with spaces within new_dir_name it will still be treated as a single argument of mkdir by the shell).

Maybe you need complex file system operation to occur every time a user does an action. In that case, I'd set up a script that listens for jobs to be added to a queue in a database, and then runs those tasks from your user account. Be sure to sanitize input coming into your database (so your tasks aren't shell injectible).