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.


2 Answers 2


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.

  • 1
    But according to my understanding the Linux operating system is specifically designed with this scenario in mind that if a user is somehow compromised, it can not be used to damage the entire system. I mean that's why permissions are in place, aren't they?
    – 2hamed
    Aug 22, 2012 at 15:54
  • 2
    That's true, SELinux and priviliges do a good job of offering basic compartmentalization, but they're not fool proof. For an attacker, very simple exploits exist to allow for user privilege escalation, once you're at the command prompt. It would take skill, but it's by no means impossible. For people that manage their own servers and code, the risk of injection attacks can be properly mitigated. In this case though, since you're renting space, the provider has no way of knowing how secure your code is, and has simply decided to avoid the risk all together.
    – Univ426
    Aug 22, 2012 at 16:00
  • 6
    @EdwinDrood If only that were true! A user can still run commands that eat up massive amounts of RAM or CPU cycles, completely killing the server. If the kernel or a privileged command is vulnerable, they might also upload a privilege escalation exploit and jump to root privileges.
    – Polynomial
    Aug 22, 2012 at 16:01
  • @Polynomial Nice point you got there. So I take it for granted that they have this right to disable these functions and deny the users the use of them.
    – 2hamed
    Aug 22, 2012 at 16:04

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

You must log in to answer this question.

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