Letting apache run commands using PHP's exec or proc_open commands...security risk?

[ltwinner]

I have a web page that lets users enter commands and then I am using proc_open()/exec() in php to run these commands on the terminal.

I sent in the command 'whoami' and it returned 'www-data' which represents apache afaik. So is this a security risk, does anyone know what this www-data user is and isn't allowed to do on a system?

I sent in the command 'rm delete_me.txt' to delete a file called delete_me.txt which is stored in a subfolder of the apache document root /var/www/subfolder/ and it wouldn't delete the file, it gave an error saying -

rm: cannot remove `/var/www/subfolder/delete_me.txt': Permission denied

So that seems pretty promising security wise, considering it won't even let www-data delete files from apaches own document root...

[ltwinner]

So I've looked into it a bit more and /var/www/ and it's subfolders are owned by root, hence why the www-data user can't delete items in them. However I ran the command 'cat /home/me/read_me.txt' and i was able to read the file.

This is obviously unacceptable, I can't have user's reading any file they want to on the system. So is there a way of limiting the www-data user to only have permission to do anything inside the /var/www/ directory?

[SlugSlug]

Your giving the world shell access to your box.

they could wget some code and quite possibly execute it under www-data.

Its a whole can of worms

but you can limit your /home/me to only you

chmod 750 /home/me

[ofnuts]

Your giving the world shell access to your box.

they could wget some code and quite possibly execute it under www-data.

Its a whole can of worms

but you can limit your /home/me to only you

chmod 750 /home/me

Until a new exploit comes along...

You can't really achieve any level of security if you allow your users to execute arbitrary commands.

[SlugSlug]

Until a new exploit comes along...

You can't really achieve any level of security if you allow your users to execute arbitrary commands.

Don't get me wrong - I strongly advise against this!

[RWhitney]

I have a web page that lets users enter commands and then I am using proc_open()/exec() in php to run these commands on the terminal.

I sent in the command 'whoami' and it returned 'www-data' which represents apache afaik. So is this a security risk, does anyone know what this www-data user is and isn't allowed to do on a system?

I sent in the command 'rm delete_me.txt' to delete a file called delete_me.txt which is stored in a subfolder of the apache document root /var/www/subfolder/ and it wouldn't delete the file, it gave an error saying -

rm: cannot remove `/var/www/subfolder/delete_me.txt': Permission denied

So that seems pretty promising security wise, considering it won't even let www-data delete files from apaches own document root...

Whether or not it can delete files is not the issue, the user is still able to execute commands which is bad, nothing is stopping someone from downloading a shell into the /tmp folder of the system and launching it so that they can perform a tcp connection onto their terminal and load into that shell.
From this point they may download other files such as privilege escalation exploits which will allow them to eventually crack into root privileges. Given the experience of any given hacker, this could take only minutes to accomplish.

The goal of security here should be to create as few possibilities for an attacker to enter your systems command line as possible.

I would therefore concluded that yes, this is a security risk and should be removed immediately from your web server.

[RWhitney]

So I've looked into it a bit more and /var/www/ and it's subfolders are owned by root, hence why the www-data user can't delete items in them. However I ran the command 'cat /home/me/read_me.txt' and i was able to read the file.

This is obviously unacceptable, I can't have user's reading any file they want to on the system. So is there a way of limiting the www-data user to only have permission to do anything inside the /var/www/ directory?

And all aside from my last note, they would also be able to read your /etc/passwd file which contains most user data from the system, this right there allows them to learn user names of all those who have access to your box, which can open up another "can of worms" in which they could attempt to brute-force or launch a dictionary attack on your SSH logins in attempt to gain access as well. but why should they need to do that when hell, you are giving them a shell right off the bat! lol. I'd call it quits with this and delete the PHP shell from the drive.

[ltwinner]

And all aside from my last note, they would also be able to read your /etc/passwd file which contains most user data from the system, this right there allows them to learn user names of all those who have access to your box, which can open up another "can of worms" in which they could attempt to brute-force or launch a dictionary attack on your SSH logins in attempt to gain access as well. but why should they need to do that when hell, you are giving them a shell right off the bat! lol. I'd call it quits with this and delete the PHP shell from the drive.

It seems you are saying that this www-data user can do anything they want on the system...

Linux seems wide open security wise from what you are saying. If any user (and www-data is just another user) who has an account on the system can do whatever they want and raise their privileges through some means then Linux is completely unsecure as a multi user system.

So what is the point of even having a root user or an adminstrator group if any user with an account on the system is capable of exploiting the system?

[ltwinner]

So is this safe to do or not? Does anyone have a definitive answer?

[SlugSlug]

Well it's going to open your system up to the world. You'd be better creating shell access for users you trust.

You'd need to know your all file permissions are correct.

Be aware that www-data would be able to spy to a certain degree

(eg. ps -ef might show firefox pages open)