Are You Getting Open_BaseDir Restriction Errors From Scripts and WordPress Plugins?

I don’t know a secure solution but I do know the cause. The cause is a PHP security restriction. It’s a good one to have and shows your host cares about you and other users on your server.

A typical open_basedir error looks like this:

The open_basedir restriction is a security feature used on some servers. It prevents hackers from getting into different areas of your hosting space by, for example, exploiting a php script bug to upload a PHP shell script which would give a hacker access to your server and its files. This method of attack is what is called RFI (Remote File Inclusion) and was heavily used by TimThumb hackers.

The open_basedir restriction is configured in either php.ini – to globally set the top most directory that can be accessed by PHP scripts – or it is set in each virtual domain’s Apache2 config file (on Apache servers, anyway). The latter option is favored because it better limits access to directories on a per site basis.

Here’s What it Does

Let’s assume the server directory path to your domain is at /var/www/your-website-one/

Let’s assume you have another site at /var/www/your-website-two/

Without an open_basedir restriction in place, if a hacker uploads a PHP shell script into /your-website-two/ then the hacker will be able to cd all the way up to and beyond /var/. That is to say the hacker will be able to create, view, edit and delete files stored anywhere on the server, whether in just your server space or not.

If open_basedir is set in the virtual host file for your-website-two, so that it restricts the top-most accessible directory for that directory to /var/www/your-website-two/, then no hacker will be able to view above /your-website-two/ should a PHP shell script be uploaded to that directory or any subdirectory within it. This helps limit the damage that can be caused.

All Hosts Should Automatically Set the open_basedir Restriction

Using WordPress as an example, the open_basedir restriction is in effect error usually occurs when a script tried to find wp-config.php.

The reason you might get the error with, for instance, WordPress scripts is that your host has set the restriction and WordPress, being the clever bundle of scripts that it is, lets you place the wp-config.php file one directory above the root WordPress index.php file. This permits you to hide wp-config.php – which holds your database username, database password and database location – away from prying eyes. WordPress will automatically look above its own directory to locate wp-config.php if it can’t find wp-config.php in the same directory as the main index.php file.

For some reason, some plugins such as Quick Cache show an error because thay can’t view above the allowed top most directory as set by the open_basedir PHP parameter. Whether it negatively impacts the functionality of such plugins is something I don’t know. But I do know I feel more secure using servers that set the parameter whenever a new domain or addon domain is created because it means I need to worry less about the sloppy security practices of my shared server neighborhood.

The Solution

And I’m not being flippant, change your script o contact the script developer, point him/her to this blog post and ask for a fix to be released. Alternatively, and I don’t recommend this, raise the open_basedir one directory. The final solution is not ideal because it leaves your server unprotected.

If you want to see what a PHP shell script can do then I recommend you download one from Sourceforge, place it one your server while you test it then delete the shell script’s files immediately you’ve finished with it. Certainly do not leave it one your server longer than an hour in case a bot probes for it.

PHP shell scripts are not purely maliciously used. They are handy tools for when a host doesn’t provide SSH access or for when you need a little bit more access to your server. I was surprised by what these things do when I first tried one on my home LAMP server.

Leave a Reply