WordPress, PHP, and Shared Hosting

With WordPress more popular than ever, boutique hosts are popping up everywhere offering the promise of “bulletproof” hosting. For those that don’t have the resources to administer a VPS, a managed environment tuned for performance, security, and reliability seems worth paying the extra expense. After vetting three of these services for a project, my advice is “Be careful.” Not all services are created equal.

The Problem

Shared PHP hosting requires a careful system admin. In a typical mod_php Apache httpd installation, all virtual hosts share the same Apache instance running with the same permissions. Unless special precautions have been taken, any PHP file can read/write/execute any file that the Apache process has permission to read/write/execute. Deploying in this situation means that you must trust all of your neighbors.

Over the last week, I tested three managed WordPress hosts. How did they fare? Not, good. Two hosts with a good reputation in the community have serious vulnerabilities. The vulnerabilities are severe enough that I could easily manipulate the data of an adjacent installation.

How do you know if your host is vulnerable?

Below is a script borrowed from phpsec.org:

<?php

echo "<h3>Current directory:" . dirname(__FILE__) . "</h3>\n";

echo "<pre>\n";

if (ini_get('safe_mode'))
{
    echo "[safe_mode enabled]\n\n";
}
else
{
    echo "[safe_mode disabled]\n\n";
}

if (isset($_GET['dir']))
{
    echo "<h4>Scanning: " . htmlentities($_GET['dir']) . " </h4>\n";
    ls($_GET['dir']);
}
elseif (isset($_GET['file']))
{
    cat($_GET['file']);
}
else
{
    echo "<h4>Scanning: / </h4>\n";
    ls('/');
}

echo "</pre>\n";

function ls($dir)
{
    $handle = dir($dir);

    while ($filename = $handle->read())
    {
        $size = filesize("$dir$filename");

        if (is_dir("$dir$filename"))
        {
            if (is_readable("$dir$filename"))
            {
                $line = str_pad($size, 15);
                $line .= "<a href=\"{$_SERVER['PHP_SELF']}?dir=$dir$filename/\">$filename/</a>";
		if(is_writable("$dir$filename"))
		{
			$line .= " (writable)";
		}
            }
            else
            {
                $line = str_pad($size, 15);
                $line .= "$filename/";
            }
        }
        else
        {
            if (is_readable("$dir$filename"))
            {
                $line = str_pad($size, 15);
                $line .= "<a href=\"{$_SERVER['PHP_SELF']}?file=$dir$filename\">$filename</a>";
		if(is_writable("$dir$filename"))
		{
			$line .= " (writable)";
		}

            }
            else
            {
                $line = str_pad($size, 15);
                $line .= $filename;
            }
        }

        echo "$line\n";
    }

    $handle->close();
}

function cat($file)
{
    ob_start();
    readfile($file);
    $contents = ob_get_contents();
    ob_clean();
    echo htmlentities($contents);

    return true;
}

?>
  1. Copy the code to your favorite editor, save as dir-scan.php, and upload to the root of your web directory.
  2. Visit the page by going to http://hostname.com/dir-scan.php
  3. When the page loads, you will see the current directory, whether safe_mode is active, and listing of the files/directories in “/”. If no files are listed that is good.
  4. To view a specific directory, go to http://hostname.com/dir-scan.php?dir=/var/www/path.

2 thoughts on “WordPress, PHP, and Shared Hosting

  1. You don’t seem to be advocating one way or the other, but it’s worth noting that safe_mode is deprecated in PHP 5.3. Even in builds of PHP that still include it, it’s not a productive way to secure a hosting environment. Many of the best shared hosts use PHP with with the CGI/FCGI SAPI in order to have more fine-grained control over the security issues you’re discussing here. Mod_php is excellent software but is not appropriate in all situations.

    1. Thanks, Josh. I should have provided the details of each host’s server configuration. One host was using FastCGI with Litespeed, but there was a configuration issue, which caused the vulnerability. The host that I found to be secure was using mpm-itk with all of the provisioning and system-level scripting done in ruby. And I don’t remember how the host that had system-level scripts executing right along side customer code was set up. Although I guess that doesn’t really matter because no setup can make that system design secure.

      In all cases, I think a monitoring script that checks for known potential vulnerabilities is a prudent approach.

Leave a Reply to Josh Butts Cancel reply

Your email address will not be published. Required fields are marked *