PHP Safe Mode and Viable Alternatives
This article is about PHP safe mode – one of the most controversial PHP security features. [alert]PHP Safe Mode is disabled on all servers at Jolt, read on if you want to know why.[/alert]
What is PHP safe mode
PHP safe mode was one of the attempts to solve security problems of shared web hosting servers.
It’s still being used by some web hosting providers, however this is impropriety nowadays. Systematic approach proves that it’s architecturally incorrect to try solving complex security issues at the PHP level rather then at the web server and OS levels.
Technically, safe mode is a PHP directive that restricts the way some built-in PHP functions operate. The main problem here is inconsistency – when turned on, PHP safe mode may prevent many legitimate PHP scenarios from working correctly. At the same time there exists a variety of methods to override safe mode limitations using PHP functions that aren’t restricted, so if a hacker has already got in – safe mode is just useless.
Some past best practices suggested to combine enabling safe mode with adding certain functions into disabled_functions parameter in php.ini configuration file. In this case safe mode restrictions are applied first, and then specific functions are completely disabled. Again, the problem is inconsistency – there’s no reliable method to determine a potentially dangerous function. For example, is creating a symbolic link dangerous? The correct answer is: it may be dangerous in some cases, but your software may need this function for normal operations. [alert style=”danger”]Safe mode feature has been deprecated in PHP 5.3.0 and removed in PHP 5.4.0. – this is a clear sign that it should not be relied upon anymore.[/alert]
How does PHP safe mode work
With safe mode set to on, PHP checks if the owner of the current script matches the owner of the file to be operated on. For example, we have the following file in /var/www directory:
-rw-r--r-- 1 apache apache 21 Feb 26 19:00 script.php
It contains the following code:
<?php readfile ('/home/list.txt'); ?>
We also have list.txt file in /home directory that should not be available to public:
-rw-r--r-- 1 root root 22 Feb 26 19:03 list.txt
Executing script.php will result in error like this:
Warning: SAFE MODE Restriction in effect. The script whose uid is 48 is not allowed to access /home/list.txt owned by uid 0 in /var/www/script.php on line 2
This only seems to be safe. If a script kiddie gets access to your web directory the following code will work:
<?php echo nl2br (htmlspecialchars (implode ('', file ('/home/list.txt')))); ?>
This will display everything from list.txt file. Besides that, any information, even PHP or bash code can be in a similar way inserted into list.txt if the file is writeable.
Why “safe_mode = On” is dangerous
So what has happened in the above example? Two things:
1. If your script needs to read the list.txt file to operate normally – it won’t be able to because of safe mode.
2. If a beginner attacker got access to your web directory – he’ll be able to access list.txt regardless of safe mode.
Theoretically, you can set up a smart combination of safe_mode, disabled_functions and open_basedir settings in a way that the above scenario won’t happen. However, you’ll also have to rewrite all your scripts to operate under all those restrictions, and this may turn out to be impossible to achieve.
This chap, having spent time and efforts, will get used to wearing his gas mask every day, but he can still be hit by a truck on the street.
Jolt Experts confirm that using safe mode in PHP is not only pointless in terms of security and potentially harmful for legitimate applications. It’s also dangerous, because it establishes a false sense of security.
All this becomes a non-issue in PHP 5.4.0 and on, but if you’re using earlier versions of PHP in production – avoid using safe mode, use alternative security tools and consider upgrading your web applications to ensure compatibility with the latest stable PHP version.
Alternatives to PHP safe mode
Securing PHP is not trivial. It’s a multi-factor process involving many aspects of server operations. Besides that, PHP-based web applications can be vulnerable on code level and this negates pretty much any properly secured environment.
However, while all these problems cannot be entirely prevented – their impact in case of the worst scenario can be minimized. With PHP safe mode proven to be ineffective, the best alternative to it so far is suPHP – a tool that executes PHP scripts with the permissions of their owners thus effectively isolating processes on a per-user basis.
Up until PHP 5.3.3 a PHP-FPM patch can be used which later became a part of PHP core.
A Web Application Firewall ModSecurity is available for Apache, IIS and nginx. By establishing an external security layer it can detect and prevent attacks before they even reach your web application.
Finally, there is Suhosin – an advanced protection system for PHP installations that was designed to protect servers and users from known and unknown flaws in PHP applications and PHP core.
The winner is …
And the winner is … A perfectly crafted PHP application is the winner, something that scarcely exists nowadays.
But there’re no losers (except PHP safe mode) as well. All mentioned tools are of great help, no matter if you’re using existing PHP-based softwares or relying on your own code. And there’re no hard times to start building a properly secured infrastructure either. All these tools are supported in cPanel, so a secure hosting server will be up and running in minutes.