I've got a sticky question in my mind: safe_mode has removed in PHP 5.4, so what is the security in this removal?
Does it mean that any application can execute any program?
What technique is used for this purpose to prevent such violent actions?
This article Will explain you why safe_mode has never made a single bit of sense and only provides you a false sense of security.
safe_mode was trying to solve a security problem with the wrong tool. Since shared webhosts often host thousands of websites on one server, safe_mode was a convienent (and entirely inappropriate) method to restrict the damage one could do with PHP.
It was an illusion more than anything else. Though PHP may have been protected with safe_mode, what about other languages like Python and Ruby? The proper method is to use default linux file permissions and modules like suPHP which run PHP as restricted users.
Related
PHP 5.4 finally removed safe_mode and magic quotes.
Are there any alternatives to them? To enhance the security level?
I think the point of removing these features is that the PHP development team acknowledges that implementing security features/mechanisms in the application stack is not a panacea for securing Web applications.
There shouldn't be direct code/configuration substitutes for these features in PHP. Instead:
application developers should be more explicit about such things as reading in values from requests and the environment AND validating and escaping values, instead of letting features like register_globals and magic_quotes do so indiscriminantly.
system engineers and system developers should consider permissions for all filesystem resources required by an application rather than having safe_mode limit the accessiblity and efficacy of built-in functions.
I'm sure someone will try to figure out how to re-create these features, and there will be a lot of late adopters that choose to stay on earlier versions of PHP instead of addressing security directly. But if you really are concerned about security, don't look for shortcuts.
Question about PHP safe-mode:
By default it is switched on in PLESK shared-hosting account environment:
While on my site seems to work fine, but maybe it will work faster/better when off?
I dont understand the below text very well, especially PHP's explanation:
PLESK:
By default, PHP is configured to operate in safe mode with functional restrictions. Some web applications may not work properly with safe mode enabled: If an application on a site fails due to safe mode, switch the safe mode off
PHP.net:
This feature has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged. The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now.
Question1: When/for what reasons should folks turn Safemode ON?
Question2: When/for what reasons should folks keep Safemode OFF?
Turn it off. Always leave it off.
It was designed way back when as a way to make PHP safe to use on mass hosts, and let the hosts "lock down" PHP.
But over time, it was realized that this didn't really work, and didn't really solve the problem anyway. There are better system-level ways of securing servers. So PHP is removing the functionality in the next major version and has it deprecated.
So to directly answer your questions:
When should folks turn it on:
Never. It doesn't really work, and it limits what you can do with PHP in a sane way, so just don't turn it on.
When should folks keep it off:
Always. It doesn't really work, so there's no point to turning it on...
That's my $0.02 anyway...
Edit: Some references
Everything you can do to a server, you can do with Safe Mode on, including: It's possible to write to the webserver anyway. So what's the point?
A mailing list thread from PHP about removing it in 6
Edit2: About speed:
The speed difference is likely to be trivial at best. It's no more than a micro-optimization. You're going to get a far bigger gain by writing your code well than worrying about a specific configuration option such as this. Don't worry about the speed difference at all. Build your application properly, and worry about speed later. Not to mention that the choice of front end web server (Apache, IIS, Lighttpd, NginX, etc) and SAPI (mod_php, CGI, FastCGI, etc) will make a far bigger difference than safe_mode ever can...
Safe mode adds some limits to filesystem-related functions and process handling features (and some totally unrelated cURL options). It's nowadays considered pointless, as it can be circumvented on shared hosting servers by resorting to Perl or Python or bash-CGIs. Professional hosters use suexec and mod_chroot rather.
It can be beneficial if you want to run outdated scripts however (wether that's a good idea is open for discussion). While it doesn't solve all problems, the limitations can help to mitigate risks. It's thus a best effort solution like mod_security.
As far as speed is concerned; it's measureable but not significant.
I would like to host a few 3rd party PHP scripts on a Windows server (running in VMware), so I am looking for a way to limit all the users to accessing their own directories (and subdirectories) and prevent them from executing anything on the machine.
Port 25 is completely blocked and there is a very low limit on the number of external connections they are allowed to make.
There must be others that have come across this issue and any ideas, advice and tips are welcome.Thanks!
For PHP, there's the open_basedir restriction that is supposed to limit PHP script access to certain directories, and it usually does. However, it seems to be flawed. Article here - It's from 2008 though, so the shortcomings described there may have been already addressed in a recent release.
There's also the much hated safe mode that may have its place until PHP 6 comes along (it will be removed there.) be very careful with allowing scripts to execute outside binaries.
Suhosin adds additional security and restriction possibilities to PHP and is certainly a good idea to install. Its defaults may interfere with more complex apps, so be sure to look deeply into its config file. However, it looks like you have to recompile PHP to get it running on Windows. This is something I would really recommend looking into.
If you need something stronger and can use Linux, putting Apache in a chroot jail is something I came across a few days ago. It looks totally advanced, though.
How can I disable the dangerous eval function? Can that be done using ini_set function?
Also how to disable following functions? Can we disable them using ini_set function?
allow_url_fopen
allow_url_include
exec
shell_exec
system
passthru
popen
stream_select
eval is one of the most dangerous function that bad guys can use to exploit the things. There should be a mechanism to disable that without resorting to php.ini file; but is should be done programatically.
Well, guys I am looking for an answers suggesting disabling of these dangerous lovely fellows without going to php.ini file; I mean how to disable them at runtime or programatically?
Thanks in advance....
Update
Has anyone heard about PHP Shell Offender Script? It mainly used the eval function for the exploit. Hackers are able to run their PHP code on your site.
My question was that I don't want to disable the eval function from php.ini file altogether. For example, i have developed my own MVC framework. Now the framework users can specify from frameworks config file whether eval (and others) function should be disabled or not. So this is left to the choice of framework users. Once they specify to disable it; i should be able to disable the eval function programatically.
So that is the scenario. Looking for helpful answers/solutions.
Thanks Again.
Afraid you're pretty much stuck using php.ini to disable most of those. However, it gets worse. eval() is technically not a function, it is a language construct, so it CANNOT be disabled using disable_functions. In order to do that, you would have to install something like Suhosin and disable it from there.
A good webmaster should consider a security review to be an essential part of site setup. Do not try to completely abstract this away, people are lazy enough about security already. If you are going to use tools (like a webhost), you should take the initiative to have at least a cursory knowledge of how to manage one responsibly.
That said, there are some other things you can do to severely cripple most hack attempts, including:
-Disable base64_decode() using disable_functions. Now, there are ways around this, however the vast majority of hack scripts are generic in nature, and this will break about 95% of them as they require the existence of BOTH of these functions in order to operate properly. This does not mean that your server cannot be hacked, but in most cases it would incur the overhead of manually sniffing your server for vulnerabilities, and most hackers are playing the numbers and ain't got time for that (NOTE: some hackers do have time for that, this is not a magic bullet by itself).
-Filter all input for common other exploit string patterns like <?php, which is frequently used to squeak by an opening php tag unnoticed. There are several such patterns. Best practice is to whitelist specific characters and reject all others on a per-input basis. At the very least, filter the aforementioned, null terminators, and possible sql injection strings such as '; -- (do not assume that simply using pdo or mysqli is going to filter ALL injection attempts, there are still some ways to pull this off even if you are properly using prepared statements).
-Any directories that serve only media should have all script access disabled, and all uploads and media should be placed only in such a directory. It is better to whitelist only the acceptable media rather than blacklist scripts, as there are any number of ways to execute a script file (eg: php, php5, phtml, etc) which individually may or may not be available on any given server environment. You can do this with a simple .htaccess placed in the media directory similar to this:
php_flag engine off
AddHandler cgi-script .php .php3 .php4 .phtml .pl .py .jsp .asp .aspx .htm .html .shtml .sh .cgi
Options -Indexes -ExecCGI
<Files "\.(jpe?g|png|gif|bmp|tiff|swf|flv|mov|avi|mp4)$">
order deny,allow
deny from all
</Files>
This part can be dynamically written by php, so your application would be capable of securing sensitive directories in a manner similar to this, which can mitigate a great deal of hacker pain, as this is typically overlooked. I typically add a similar .htaccess to almost every Wordpress site I work on in the uploads directory, and have often wondered why this is not done out of the box, as it blocks a great deal of hack attempts and does not interfere with the application in any way that I have noticed.
Unfortunately, if you are not on an apache server, you will need to find another solution (on IIS there is most likely an equivalent, but I am not aware of what it would be personally).
-You should also configure your .htaccess (or web.config/etc) to disable any access methods that are not needed for your specific application. If you are not doing RESTful web services, there is really no reason to allow PUT or DELETE, you should almost certainly also disable TRACE, and probably also don't really have any reason to leave OPTIONS or HEAD enabled either. It should also be mentioned that all non-recognized connection methods by default resolve to GET, which means that from the command line I can do something like:
curl -X BOOGITY -d arg=badstuff -d arg2=morebadstuff yoursite.com
In this example, BOOGITY is meaningless, however, your server will interpret this as:
curl -X GET -d arg=badstuff -d arg2=morebadstuff yoursite.com
However your application likely will not.
In order to prevent this, you should configure your server to accept only GET as GET, and not allow it to be the default.
In most cases, the primary point is not to make it difficult to execute specific php patterns in your environment, the point is to prevent the inclusion of rogue code (either locally or externally) so it does not become an issue. If you are allowing the installation of modules or such into your CMS, sloppy programmers WILL eventually create exploits, which you cannot really do much about aside from enforcing pretty stringent API parameters that make it very difficult to do it poorly, but it can never be made impossible. Never underestimate the capacity of an offshore hack shop or self proclaimed "php ninja" to diligently work with your system in the most insecure or non-compliant way possible, create massive vulnerabilities, and to invent any number of roundabout hacks to do so that are actually harder to pull off than just doing it the right way.
/security rant.
To disable functions, mainly for security reasons, you can use the disable_functions directive in your php.ini configuration file.
But, as the documentation states :
This directive must be set in php.ini
For example, you cannot set this in
httpd.conf.
I suppose this is too "internal" to be configurable anywhere else than in PHP... And as it's security related, it's up to the system administrator to configure it.
Still, the best security measure is to write clean/secure code, filter all input, escape all output... And not let anyone run their own code on your server !
In short: you can't do that.
But I think you don't really understand how eval and those functions are exploited. The problem occurs when programmers do not sanitize properly the ARGUMENTS that are passed to them.
The php shell offender script that you mentioned is just a simple PHP script passing arguments to those functions. But the attackers already had a way of injecting/uploading the malicious script. If you are not using these functions at all nor passing arguments from user input, attackers can't run arbitrarily code on your server using eval() or relatives.
Are you going to be hosting this framework for your users? If you are allowing users to upload and run code then you have a bigger problem in your hands.
Read about remote code execution and remote/local file inclusion here to learn more about attacks related to this: Common PHP vulnerabilities
The disable_functions directive is only available in the php.ini configuration.
To disable functions at runtime wouldn't make much sense, since you would be able to modify the disabled function list at runtime to re-enable functions as well.
You can disable eval through https://github.com/mk-j/PHP_diseval_extension and gets around the issue of suhosin not being php7 compatible/stable.
Add this line to your php.ini (you Search for 'disable_functions')
disable_functions =exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
Then restart your php service (apache or php-fpm)
E.g. Is it more secure to use mod_php instead of php-cgi?
Or is it more secure to use mod_perl instead of traditional cgi-scripts?
I'm mainly interested in security concerns, but speed might be an issue if there are significant differences.
Security in what sense? Either way it really depends on what script is running and how well it is written. Too many scripts these days are half-assed and do not properly do input validation.
I personally prefer FastCGI to mod_php since if a FastCGI process dies a new one will get spawned, whereas I have seen mod_php kill the entirety of Apache.
As for security, with FastCGI you could technically run the php process under a different user from the default web servers user.
On a seperate note, if you are using Apache's new worker threading support you will want to make sure that you are not using mod_php as some of the extensions are not thread safe and will cause race conditions.
If you run your own server go the module way, it's somewhat faster.
If you're on a shared server the decision has already been taken for you, usually on the CGI side. The reason for this are filesystem permissions. PHP as a module runs with the permissions of the http server (usually 'apache') and unless you can chmod your scripts to that user you have to chmod them to 777 - world readable. This means, alas, that your server neighbour can take a look at them - think of where you store the database access password. Most shared servers have solved this using stuff like phpsuexec and such, which run scripts with the permissions of the script owner, so you can (must) have your code chmoded to 644. Phpsuexec runs only with PHP as CGI - that's more or less all, it's just a local machine thing - makes no difference to the world at large.
Most security holes occur due to lousy programming in the script itself, so it's really kind of moot if they are ran as cgi or in modules. That said, apache modules can potentially crash the whole webserver (especially if using a threaded MPM) and mod_php is kind of famous for it.
cgi will be slower, but nowadays there are solutions to that, mainly FastCGI and friends.
What is your threat model?
From the PHP install.txt doc for PHP 5.2.6:
Server modules provide significantly better performance and additional
functionality compared to the CGI binary.
For IIS/PWS:
Warning
By using the CGI setup, your server is open to several possible
attacks. Please read our CGI security section to learn how to defend
yourself from those attacks.
A module such as mod_php or FastCGI is incredibly faster than plain CGI.. just don't do CGI. As others have said, the PHP program itself is the greatest security threat, but ignoring that there is one other consideration, on shared hosts.
If your script is on a shared host with other php programs and the host is not running in safe mode, then it is likely that all server processes are running as the same user. This could mean that any other php script can read your own, including database passwords. So be sure to investigate the server configuration to be sure your code is not readable to others.
Even if you control your own hosting, keep in mind that another hacked web application on the server could be a conduit into others.
Using a builtin module is definitely going to be faster than using CGI. The security implications depend on the configuration. In the default configuration they are pretty much the same, but cgi allows some more secure configurations that builtin modules can't provide, specially in the context of shared hosting. What exactly do you want to secure yourself against?