how do I disable phpsuexec? - Page 2

fhltang · April 21st, 2006, 7:15 PM

Quote:

Originally Posted by Haugland

There's obviously benefits to running as phpsuexec, but it also lowers security in different areas.

Precisely! (Thank you Haugland.)

I agree completely. Some people on this forum portray phpsuexec as the best thing since sliced bread and/or without any faults.

Writing "correct" code is certainly desirable, but unfortunately we're still a long way off from dependable ways to get reasonable guarantees of code quality.

Without phpsuexec, there was a relatively simple mechanism - namely that of the OS's file permissions system - to be able to sandbox php applications [edit: sandbox it from *my* files, rather than other people's www files]. For example, by simply making sure my mail folders are owned by me:mail and have 660 perms, I have a fairly reasonable guarantee that any process running as nobody (i.e. php apps in a pre-phpsuexec era) won't be able to read or write to them.

With phpsuexec, this is no longer the case. Now, if surpass gives us two accounts per package - one for mail and one for www - that will give something near the best of both worlds (i.e. your php apps are isolated from other users' files, and furthermore they're isolated from your non www files).

**cowboy** · April 21st, 2006, 8:58 PM

Quote:

Originally Posted by fhltang

Without phpsuexec, there was a relatively simple mechanism - namely that of the OS's file permissions system - to be able to sandbox php applications [edit: sandbox it from *my* files, rather than other people's www files]. For example, by simply making sure my mail folders are owned by me:mail and have 660 perms, I have a fairly reasonable guarantee that any process running as nobody (i.e. php apps in a pre-phpsuexec era) won't be able to read or write to them.

PHPsuExec involves PHP only. It does not deal with Mail. Mail ownership (inbox) remains "me:mail" [user:group] with 660 permissions.

6xx -> me; read and write.
x6x -> mail; read and write.
xx0 -> world, nobody, 99; gets to do nothing.

PHPsuExec does not affect: apache, perl, ruby, OS, etc. --- only PHP. Since PHP cannot execute higher than the public_html folder, it cannot mess with any of those files.

Any files within the public_html directory and subdirectories that do not have a PHP executable extension (.php, .phtml, etc.) also are not involved and can be given any permission you want as long as it has at least a read bit, minimum 444, ie., a 444 .jpg will read and display in a browser but not even the user can overwrite with a PHP script.

If you need to write to a file it has to have a user write permission (6xx) and owned by the user and have a group of the user.

H · April 22nd, 2006, 1:25 AM

I don't feel like typing a lot, so I'll keep this short.

What's preventing someone from using a script to view mail within the mail folder? If the folder has read access it's possible.

Sure, PHP can't be executed above public_html, but it can certainly read and write to that area. I do it all the time actually. Whenever I write any new scripts, the database connection is never within the public folder. If I have ownership of the folders, I can go back to root if I wish.

And once again, while 0444 may stop someone from overwriting, there's nothing stopping someone from chmodding that file to 0755 or 0777 prior to overwriting.

Because of the ownership that phpsuexec gives to PHP scripts, they have a lot more freedom with the filesystem. Deny it all you wish.

**cowboy** · April 22nd, 2006, 4:56 AM

My intent is not to deny anything, but rather to help others having a problem with their sites that use PHP after the decision to activate phpSUexec on all servers. That decision has been made without any consultation with me. We simply need to help with getting the problems solved.

I agree 100% with haugland's last post, when PHP is run as an apache module.

Script exploits stem from someone devising a way to write a script file to your space without a FTP password and make it run, doing things like changing file permissions, changing file content, and even deleting files. This can be done relatively easy when "nobody" or "the world" is allowed the right to run their scripts in someone else's space, generally referred to as 'hacking'.

The tool which has been made available that removes this very relaxed method in which Apache allows PHP to run, to that of a 'Common Gateway Interface' (CGI), is this new activation of PHPsuExec.

With the ability of "the world" or "nobody" running these renegade scripts using Apache, a potential equal to the total users on the internet has access to run these files in your own space. Millions.

Allowing only one user to write a file to your space, the one who has the FTP password, the odds are reduced from Millions to One.

Personally, I like those odds. I like them so well that I also use the Apache suexec module and force Apache to adhere to "set user" rules. My sites will even refuse to honor execution commands from scripts I might upload as the Server Administrator leaving them belonging to the big boss "root".

Each domain has a unique user and they can only work outside of their space by the scripts owned by the user, requesting root intervention.

Be concerned by the owner of the file. A file permission between 0444 and 0755 will work (directories 0755) and at the same time not leave cause for security breach. As has been noted in haugland's post, anyone can chmod a file in Apache. Only a user/owner can write a file with PHPsuExec.

Today I see someone else is still confused as to who owns the files. I have written the following script for anyone to copy and name fileinfo.php and upload to their public_html directory. Running http://yourdomain/fileinfo.php will let you enter a path and file or directory name and it will return the owner, group and the permissions.

Code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
            "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Help me find the file owner</title>
</head>
<body leftmargin="10" topmargin="10">
<?php 
if ($_POST){
$startscript=$_POST['source']; 
$startscript=preg_replace('/^\//','',$startscript);
$startscript=preg_replace('/^.\//','',$startscript);
$startscript="./".$startscript;
$fileowneruid=fileowner($startscript); 
$fileownerarray=posix_getpwuid($fileowneruid); 
$fileowner=$fileownerarray['name']; 
$filegroup=$fileownerarray['gid'];
$fileuserid=$fileownerarray['uid'];
$fileperms=substr(sprintf('%o', fileperms($startscript)), -4);
echo "Details for <b>$startscript</b><br><br>";
echo "Owner ID is --: $fileuserid<br>";
echo "Owner name is --: $fileowner<br>"; 
echo "Group ID is --: $filegroup<br>";
echo "File permissions are --: $fileperms<br>";
}
?> 
Enter the path (relative to this file) and name of the file or directory you want ownership and permission for:
<form method="POST" action="<?=$_SERVER['PHP_SELF']?>">
<input type="text" size=100 name="source">&nbsp;<input type="submit" name="s1" value="GO">
</form>
</body>
</html>

H · April 22nd, 2006, 2:36 PM

A bunch of good points. It's much more difficult for a 'hacker' to get a file onto the server in order to actually do damage. They'll need either FTP access or a magical script that allows them to upload whatever they wish... and then give them public access to execute it. This would be uncommon and unlikely. Very true.

But, traditionally when a file is uploaded through an exploit, it's stored on the server as 'nobody', this is when you're not under PHPseExec. This means that it doesn't have the same owner or group as files made or uploaded through FTP (which traditionally is almost all files). It can read these files and folders, but it cannot delete or alter them unless they were 0777.

Under PHPsuExec, when a file is uploaded, it will have the owner/group of your username, the same as your files and folders. This does give them the ability to alter files and delete them, ontop of reading them.

On top of that, according to PHP.NET, most systems running under Apache with the user nobody will not allow use of the chmod function. You could of course use FTP functions to do it, but that assumes knowledge of that information. If you're under safe mode, it will check this information and deny the user 'nobody' from making changes (Surpass does not use safe mode, so this is irrelevent for Surpass clients). I did not say that anyone can chmod a file in Apache, I said anyone can chmod a file under the current user under PHPsuExec.

A simple example of how PHPsuExec has more access to the file system is an image gallery.
Under Apache you would be required to either have the permissions for the destination script to 0777 or use php-FTP functions before and after to alter the permissions from 0755 to 0777.
Under PHPsuExec you aren't required any chmodding to the destination folder because the process is being run as the same owner/group as the owner of the folder.

I like PHPsuExec for a number of reasons. One of which is that it does make writing certain types of scripts much easier because you're not worrying about the file system. But, I understand that how it benefits me with the filesystem, it also benefits a malicious script put onto my server. Which again, isn't all that likely to get.

April 22nd, 2006, 4:56 AM	#13 (permalink)
cowboy Surpass Fan Excelling Contributor Joined in Nov 2005 Lives in Colorado Hosted on DEDI 928 posts Gave thanks: 2 Thanked 92 times	My intent is not to deny anything, but rather to help others having a problem with their sites that use PHP after the decision to activate phpSUexec on all servers. That decision has been made without any consultation with me. We simply need to help with getting the problems solved. I agree 100% with haugland's last post, when PHP is run as an apache module. Script exploits stem from someone devising a way to write a script file to your space without a FTP password and make it run, doing things like changing file permissions, changing file content, and even deleting files. This can be done relatively easy when "nobody" or "the world" is allowed the right to run their scripts in someone else's space, generally referred to as 'hacking'. The tool which has been made available that removes this very relaxed method in which Apache allows PHP to run, to that of a 'Common Gateway Interface' (CGI), is this new activation of PHPsuExec. With the ability of "the world" or "nobody" running these renegade scripts using Apache, a potential equal to the total users on the internet has access to run these files in your own space. Millions. Allowing only one user to write a file to your space, the one who has the FTP password, the odds are reduced from Millions to One. Personally, I like those odds. I like them so well that I also use the Apache suexec module and force Apache to adhere to "set user" rules. My sites will even refuse to honor execution commands from scripts I might upload as the Server Administrator leaving them belonging to the big boss "root". Each domain has a unique user and they can only work outside of their space by the scripts owned by the user, requesting root intervention. Be concerned by the owner of the file. A file permission between 0444 and 0755 will work (directories 0755) and at the same time not leave cause for security breach. As has been noted in haugland's post, anyone can chmod a file in Apache. Only a user/owner can write a file with PHPsuExec. Today I see someone else is still confused as to who owns the files. I have written the following script for anyone to copy and name fileinfo.php and upload to their public_html directory. Running http://yourdomain/fileinfo.php will let you enter a path and file or directory name and it will return the owner, group and the permissions. Code: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <title>Help me find the file owner</title> </head> <body leftmargin="10" topmargin="10"> <?php if ($_POST){ $startscript=$_POST['source']; $startscript=preg_replace('/^\//','',$startscript); $startscript=preg_replace('/^.\//','',$startscript); $startscript="./".$startscript; $fileowneruid=fileowner($startscript); $fileownerarray=posix_getpwuid($fileowneruid); $fileowner=$fileownerarray['name']; $filegroup=$fileownerarray['gid']; $fileuserid=$fileownerarray['uid']; $fileperms=substr(sprintf('%o', fileperms($startscript)), -4); echo "Details for <b>$startscript</b><br><br>"; echo "Owner ID is --: $fileuserid<br>"; echo "Owner name is --: $fileowner<br>"; echo "Group ID is --: $filegroup<br>"; echo "File permissions are --: $fileperms<br>"; } ?> Enter the path (relative to this file) and name of the file or directory you want ownership and permission for: <form method="POST" action="<?=$_SERVER['PHP_SELF']?>"> <input type="text" size=100 name="source"> <input type="submit" name="s1" value="GO"> </form> </body> </html> __________________ Where would you be if you were at the highest court in the land (US)?

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Rate This Thread
Rate This Thread:

April 22nd, 2006, 1:25 AM	#12 (permalink)
H after g, before i Super #1 Joined in Jul 2004 Hosted on Gojira 7,883 posts Gave thanks: 44 Thanked 127 times	I don't feel like typing a lot, so I'll keep this short. What's preventing someone from using a script to view mail within the mail folder? If the folder has read access it's possible. Sure, PHP can't be executed above public_html, but it can certainly read and write to that area. I do it all the time actually. Whenever I write any new scripts, the database connection is never within the public folder. If I have ownership of the folders, I can go back to root if I wish. And once again, while 0444 may stop someone from overwriting, there's nothing stopping someone from chmodding that file to 0755 or 0777 prior to overwriting. Because of the ownership that phpsuexec gives to PHP scripts, they have a lot more freedom with the filesystem. Deny it all you wish.

April 22nd, 2006, 2:36 PM	#14 (permalink)
H after g, before i Super #1 Joined in Jul 2004 Hosted on Gojira 7,883 posts Gave thanks: 44 Thanked 127 times	A bunch of good points. It's much more difficult for a 'hacker' to get a file onto the server in order to actually do damage. They'll need either FTP access or a magical script that allows them to upload whatever they wish... and then give them public access to execute it. This would be uncommon and unlikely. Very true. But, traditionally when a file is uploaded through an exploit, it's stored on the server as 'nobody', this is when you're not under PHPseExec. This means that it doesn't have the same owner or group as files made or uploaded through FTP (which traditionally is almost all files). It can read these files and folders, but it cannot delete or alter them unless they were 0777. Under PHPsuExec, when a file is uploaded, it will have the owner/group of your username, the same as your files and folders. This does give them the ability to alter files and delete them, ontop of reading them. On top of that, according to PHP.NET, most systems running under Apache with the user nobody will not allow use of the chmod function. You could of course use FTP functions to do it, but that assumes knowledge of that information. If you're under safe mode, it will check this information and deny the user 'nobody' from making changes (Surpass does not use safe mode, so this is irrelevent for Surpass clients). I did not say that anyone can chmod a file in Apache, I said anyone can chmod a file under the current user under PHPsuExec. A simple example of how PHPsuExec has more access to the file system is an image gallery. Under Apache you would be required to either have the permissions for the destination script to 0777 or use php-FTP functions before and after to alter the permissions from 0755 to 0777. Under PHPsuExec you aren't required any chmodding to the destination folder because the process is being run as the same owner/group as the owner of the folder. I like PHPsuExec for a number of reasons. One of which is that it does make writing certain types of scripts much easier because you're not worrying about the file system. But, I understand that how it benefits me with the filesystem, it also benefits a malicious script put onto my server. Which again, isn't all that likely to get.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)