On May 3rd, a PHP-CGI vulnerability termed as “severe” by CloudLinux was published in US CERT web site.

The vulnerability causes any server running PHP as CGI to allow source code disclosure and arbitrary command execution using the account’s privileges. The quote from US CERT web site is below:

When PHP is used in a CGI-based setup (such as Apache’s mod_cgid), the php-cgi receives a processed query string parameter as command line arguments which allows command-line switches, such as -s, -d or -c to be passed to the php-cgi binary, which can be exploited to disclose source code and obtain arbitrary code execution.

 While the primary vulnerability was reported for PHP-CGI executions, the CloudLinux note cautioned that this could be applicable to suPHP and mod_fcgid as well. But a post in suPHP mailing list says it is not affected by this vulnerability.

Response from Parallels

Parallels reacted with a 3 point resolution to this issue, as described in their KB entry on CVE-2012-1823.Important points are quoted below:

This is a Critical Vulnerability that affects software that contains PHP-CGI. PHP-FastCGI is not vulnerable to this exploit.
Parallels Plesk for Windows versions 10.4 and earlier are NOT affected.
Parallels Plesk for Linux versions 9.3 - 10.4 are NOT affected by the PHP-CGI remote code execution vulnerability due to use of the special cgi_wrapper script.
Parallels Plesk for Linux versions 8.6 and earlier are NOT affected due to use of mod_php only.
Parallels Plesk for Linux versions 9.0 - 9.2.3 might be vulnerable. Plesk team is working on an update.

1. It’s strongly recommended to update Plesk to the higher version that is not vulnerable.
2. CGI wrapper is the recommended way to workaround the issue, if Plesk update is not possible.
3. It is also possible to workaround the problem with .htaccess rules for each website.

Response from cPanel

A very reassuring post from cPanel says the customers who use EasyApache to compile their web servers are safe. cPanel though cautions that mod_cgi and mod_cgid are not recommended, and should ideally use suPHP. cPanel’s documentation says that suPHP is compiled using paranoid settings, which means that as long as you are using the latest PHP in a cPanel server running suPHP, you should be safe.

Response from CloudLinux

CloudLinux was one of the first to react to this situation, and have released a patch for those servers using PHP from CloudLinux repository. The patch is released in beta state and are awaiting a fully tested solution from RedHat. For the time being, the recommended solution is to upgrade PHP using the cloudlinux-updates-testing repo as quoted below from the CloudLinux blog post.

To deploy on CL5 (php53-5.3.3-5.el5.cloudlinux.1):
# yum update php53 –enablerepo=cloudlinux-updates-testing
To deploy on CL6 (php-5.3.3-3.el6_2.6.cloudlinux.1):
# yum update php –enablerepo=cloudlinux-updates-testing

To update PHP 5.1 on CL5 (php-5.1.6-32.el5.cloudlinux.1)
# yum update php –enablerepo=cloudlinux-updates-testing

So to summarize, if you have cPanel servers with the recommended web server settings you do not have anything to worry about. If you are using mod_cgi or mod_cgid, switch to suPHP, and you will be safe. If you are using Plesk products, upgrade to the latest release. If you have any questions, we would be happy to answer.

Visakh has been with Bobcares from May 2004, and has extensive experience in administering various control panels and operating systems used in web hosting industry. He is an avid reader, and loves topics on technology, humour and philosophy.

While discussing PHP permissions in the last blog, we concluded that SuPHP servers ideally needed PHP file permissions of just 600.

Out of many means to set the permission/ownership, the quickest is to set the permissions, using a script. You may set this script as a cron that runs daily or weekly, to take care of the the permissions. The script is now written for a server that has cPanel installed. Slight modifications to it, would make it work with other control panels, or even on servers that do not have any control panels.

The script also allows certain accounts to have custom PHP permissions, so that any custom application that needs specific permissions can be run, and such accounts would not be affected by the script.

The PHP permission script primarily does the following :

1. Changes the ownership of any PHP files(within public_html) under the ownership of nobody to the ownership of the user.

2. Changes permission of PHP files with 444 or 440 permission to 400.

3. Changes permission of all PHP files except those having 000 or 400 permissions to 600.

Steps to use this script :

1. Create /usr/local/customscripts folder

mkdir /usr/local/customscripts

2. Create the script file /usr/local/customscripts/php-perms.sh using your favorite editor.

vim /usr/local/customscripts/php-perms.sh

3. Give execute permission to the script

chmod -v 755 /usr/local/customscripts/php-perms.sh

Script given below can be used in cPanel servers which has suPHP enabled.

#!/bin/bash
export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/X11R6/bin:/root/bin;
cd /usr/local/customscripts/;
for i in $(cut -d " " -f 2 /etc/trueuserdomains)
do
if [ ! -f /home/$i/customperm.txt ]
then
find /home/$i/public_html -type f -user nobody -group nobody -name *.php -exec chown -v “$i”:”$i” {} ;
find /home/$i/public_html -type f -perm 444 -o -perm 440 -name *.php -exec chmod -v 400 {} ;
find /home/$i/public_html -type f ! -perm 600 ! -perm 400 ! -perm 000 -name *.php -exec chmod -v 600 {} ;
fi
fi
done > php-perms-log.txt

You may add this as a cron job, as outlined in the following blog : cPanel adding cron job. This measure you take for PHP security would work only if you periodically keep setting the PHP permissions right. I would suggest to set is as a cron that runs every day, or say every 12 hours.

Script compatibility : Known issues

Some custom applications like the shopping cart Interspire has the practice of setting permissions to some uploaded files(images) to the permission set for its configuration file. Say you set 777 permission to the configuration file, it will give the permission of 777 to the uploaded images. If you set 600 permission to configuration file, it will set 600 permission to all uploaded images.

In such cases, or even other cases, where you need to have custom permissions for certain accounts, you may create a file by the name customperm.txt in the home directory of the account (like /home/cpanel_username/customperm.txt). The presence of this file will make sure that the script does not act upon PHP files within that account, and you can continue to have custom PHP permissions

Otherwise, the script works just fine in all of the production shared servers, and has helped in the overall manageability of PHP permissions and have added to the PHP file security!

About the Author :

Sherin George works as a Senior Software Engineer in Bobcares. He joined Bobcares back in September 2006. He loves reading technical blogs, and listens to music in his free time..

The article describes PHP file permissions, it’s effect on PHP security and general security on servers with suPHP.

PHP permission : The common misconception

PHP file permissions have always been in discussion among people who switch to suPHP. It is one of the most common questions you would find in every webhosting forum. But then the answer in most of those forums would be to set PHP permissions to 644. How secure is 644? - The answer would be “More than 777 anyhow”.

The source of this misconception is actually related to Apache’s ability to read files, so that it could be served by it. Even with suPHP, all non PHP files, that are to be served by Apache should have permissions of 644. Rather, others (apache/nobody) should have read access to the files, so that it could be served. With suPHP, the requirement for PHP permission hence goes to 600! Read the rest of this entry »

PHP open_basedir directive is used to limit the files that can be opened by PHP to a specific directory-tree. What does that mean? With the open_basedir directive, you can tell the PHP scripts on a domain, which folders they have access to. Once specified, the PHP scripts will not be able to access files outside those folders.

Read the rest of this entry »

The article explains suPHP and setting up suPHP on cPanel servers.

Constant Phishing/Spamming complaints can get extremely tiresome, and tracking down the source of the problem is not always easy. It wont be long before your IP addresses are listed on popular RBLs and your customers start complaining about mail delivery problems. To nip these problems in the bud, we have to look for better ways to track down the source of these problems. One way of better tracking processes on a cPanel server is switching to suPHP.

Read the rest of this entry »

PHP security is very important, as insecure php code can trigger in intrusion to your server. This article explains few such vulnerabilities, so that you can avoid them in your scripts. I will also explain methods to tweak PHP config files(php.ini) for maximum security.

Read the rest of this entry »