4

My company is developing a PHP system that needs to interact with Git on the server, which can currently most conveniently be done by allowing external calls via proc_open(), system() and the likes. The problem is that our clients typically use shared hosts and those hosts typically have these PHP functions disallowed. (Well, they also typically do not have Git installed on their servers but that is another issue; let's focus on proc_open() now.)

I'd like to fully understand what are the security implications of proc_open() being allowed, and under what circumstances.

Here is what I've gathered so far:

  • If the host uses Apache + mod_php allowing proc_open() is a no-go because the PHP script and in turn the executed shell command runs under the same user (Apache) for all users on the shared host. That is obviously too much of a risk (one user could access files of the others).
  • If the host uses CGI, FastCGI, PHP-FPM or similar, and if the file permissions are set properly, allowing proc_open() should be relatively fine. The reasoning here is that the PHP script itself can already do a lot of things, so adding the ability to run external commands (with proper permissions in place) doesn't make much of a difference. (It makes some difference in that it makes the surface area larger, but the difference shouldn't be huge.)

The question is, is the above correct? Or are there examples of attacks that would be only possible via proc_open() and not otherwise? Thanks.

Borek Bernard
  • 345
  • 1
  • 4
  • 11
  • I would say yes, the above is correct if you don't pass any user-controlled variable to proc_open(). Are you using variables coming from the user when executing with proc_open() ? – r00t Jun 25 '15 at 13:59
  • No but let's assume that the client's site gets hacked and some malicious script can send whatever it wants to proc_open(). Can bad things happen then or can proper permissions still control what the user can do? Like, would for instance such malicious script be able to reboot the server or not? – Borek Bernard Jun 25 '15 at 14:04
  • Allowing this command will considerably facilitate the task to an attacker if the site gets hacked. It's like giving an ssh access to the attacker (under the account of the running php instance). He will be able to execute further exploits on the machine. It's against the "defense in depth" to allow such command on your server. – r00t Jun 25 '15 at 14:18
  • Couldn't you imagine an architecture where another program where predetermined commands are prepared (your git ones) and you talk with a socket to this program. You will be able to disable proc_open in such architecture. An attacker getting your site compromised will not have command line access. – r00t Jun 25 '15 at 14:20
  • 1
    In a shared host situation you may need to defend against other tenants of the shared host. – Neil Smithline Jun 25 '15 at 15:24
  • Many shared hosting companies will (temporarily) disable an account if it is found out to be comprised. They may do this even if you have file permissions that make the attack ineffective. Such an attack will effectively be a DoS attack. – Neil Smithline Jun 25 '15 at 15:28
  • Shouldn't the shared hosts be running apache workers as separate users in a shared hosting environment, which would mitigate this risk? – SilverlightFox Jun 29 '15 at 10:53

1 Answers1

1

It's correct that proc_open can be dangerous, if and only if there is user input going through it.

For affecting other users/websites on the server, it's a low risk nowadays since cagefs is being used, and the kernel's security is updated on the servers. So don't worry about other users: it's the hosting company's job.

schroeder
  • 123,438
  • 55
  • 284
  • 319
evexoio
  • 111
  • 3
  • it's too bad that most hosting companies that offer shared hosting packages do not give a damn about this; they will much rather sell dedicated hosting plans than implement proper security for shared hosting .. Laziness is one issue, but greed is quite another. – argon Nov 29 '18 at 23:13