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.
Related
I'm trying to obfuscate and speed up my code using Zend OpCache, but OpCache doesn't seem to have the usual functions to store bytecode in a file like other older caching systems did. As OpCache is the native method of caching files in memory in opcode, I'd like to continue using it, but I need to be able to obscure my code in the case of a system breach. (Just another security precaution)
What options do I have available to me to store my PHP files as compiled code in opcode or bytecode?
EDIT: I think people misunderstood what I was looking for for the most part. Please read my comments on the posts. I'm a professional web developer of over 12 years, so I'm not new to this. I just wanted to change my tactics a bit and see if others knew of a way to pull this off that I didn't think of.
It's definitely not a good idea to start developing your own tools for obfuscating or protecting your PHP code.
For protected your code use SourceGuardian or Nu-Coder. Both tools, however, require installing special PHP extension on server, which is not an option for many webhosting companies. These tools provide possibility to lock your code to certain machine (hardware hash, IP binding, ..), control the number of licences, expiration etc.
If you are serious about protecting your code (not only obfuscation) use virtual server + one of the tools mentioned. In run-time, both extensions hold in-memory opcached decrypted low-level code, so besides protecting the code they provide also performance boost. I tested PHP 5.5.x with loaded both SourceGuardian and opcache and there were no conflicts.
I'm currently working on developing a PHP CMF which will eventually be commercially available and I want to use traits. The problem however is that traits are a PHP 5.4 feature and apparently the popular Suhosin security patch isn't compatible with PHP 5.4.
So my question is this: is it safe to run a PHP website without the Suhosin security patch? If not, what vulnerabilities would I be leaving myself and other people using my CMF open to?
Note: I'm not concerned about shared hosting. It's expected that anyone using my CMF would have administrative control over their web server.
Suhosin was a PHP hardening patch. It did not patch any explicit security vulnerabilities -- it merely made some vulnerabilities in PHP scripts more difficult to exploit.
Some of the changes which Suhosin made were eventually rolled into PHP. For instance, Suhosin's various layers of protection against null bytes in inputs were made unnecessary by PHP 5.3.4, which made null bytes in filenames always throw an error (rather than silently truncating the filename at the null byte).
PHP 5.4 is generally regarded to be reasonably safe without Suhosin involved. Going forward, so long as your application supports it, you will be better off with a newer (5.4+) version of PHP, rather than an older version with the Suhosin patch.
If you can't disable eval() (a language construct, not a function) or have a blacklist within eval to disable most of the hacker's toolbox within eval, then you are running a load of bandwidth that is irresistable to hackers looking for bandwidth to run their payloads. What to blacklist, ideally, can't always be done because 3rd party module writers or even framework core depends on some of these functions within an eval() context:
suhosin.executor.eval.blacklist=include,include_once,require,require_once,curl_init,fpassthru,file,base64_encode,base64_decode,mail,exec,system,proc_open,leak,pfsockopen,shell_exec,ini_restore,symlink,stream_socket_server,proc_nice,popen,proc_get_status,dl,pcntl_exec,pcntl_fork, pcntl_signal, pcntl_waitpid, pcntl_wexitstatus, pcntl_wifexited, pcntl_wifsignaled, pcntl_wifstopped, pcntl_wstopsig, pcntl_wtermsig, socket_accept, socket_bind, socket_connect, socket_create, socket_create_listen, socket_create_pair,link,register_shutdown_function,register_tick_function,create_function,passthru,p_open,proc_close,proc_get_status,proc_terminate, allow_url_fopen,allow_url_include,passthru,popen,stream_select
If you can't filter for these functions then a major component of security is missing.
Here are some examples of Remote Administration Tools (RATS) that will infect your site, through any vulnerable 3rd party module or site user account.
RATs can take many forms, some are easy to grep for:
<?php error_reporting(0); eval(gzuncompress(base64_decode('eF5Tcffxd3 ...
<?php preg_replace("/.*/e","\x65\x76\x61\x6C\x28\ ...
Some are more professional and obfuscated, and cannot really be grepped for, and cannot be found unless suhosin tips you off that they executed:
<?php $_0f4f6b="\x70\x72\x65\x67\x5f\x72\x65\x70\x6c\x61\x63\x65";$_0f4f6b("\x7 ...
<?php require "./.cache/.%D59C%49AA%73A8%63A1%9159%0441"; ?>
(note in this case the CACHE directory cannot be in source control, therefore cannot be tracked either)
IMHO, the statement above from duskwuff, that things would be fine without Suhosin is neither authoritative nor necessarily correct (especially given the amount of critical holes newer PHP versions have seen since then).
To my mind, it would be definitely better - from a security POV - if Suhosin was available for current PHP version.
Of course, as it is not, staying at old (eventually unmaintained) versions of PHP isn't a solution either.
Generally PHP and especially PHP applications are notoriously known for having security issues... so the question is less "are newer PHP versions safe without Suhosin"...
I'm currently working on developing a PHP CMF which will eventually be commercially available and I want to use traits. The problem however is that traits are a PHP 5.4 feature and apparently the popular Suhosin security patch isn't compatible with PHP 5.4.
So my question is this: is it safe to run a PHP website without the Suhosin security patch? If not, what vulnerabilities would I be leaving myself and other people using my CMF open to?
Note: I'm not concerned about shared hosting. It's expected that anyone using my CMF would have administrative control over their web server.
Suhosin was a PHP hardening patch. It did not patch any explicit security vulnerabilities -- it merely made some vulnerabilities in PHP scripts more difficult to exploit.
Some of the changes which Suhosin made were eventually rolled into PHP. For instance, Suhosin's various layers of protection against null bytes in inputs were made unnecessary by PHP 5.3.4, which made null bytes in filenames always throw an error (rather than silently truncating the filename at the null byte).
PHP 5.4 is generally regarded to be reasonably safe without Suhosin involved. Going forward, so long as your application supports it, you will be better off with a newer (5.4+) version of PHP, rather than an older version with the Suhosin patch.
If you can't disable eval() (a language construct, not a function) or have a blacklist within eval to disable most of the hacker's toolbox within eval, then you are running a load of bandwidth that is irresistable to hackers looking for bandwidth to run their payloads. What to blacklist, ideally, can't always be done because 3rd party module writers or even framework core depends on some of these functions within an eval() context:
suhosin.executor.eval.blacklist=include,include_once,require,require_once,curl_init,fpassthru,file,base64_encode,base64_decode,mail,exec,system,proc_open,leak,pfsockopen,shell_exec,ini_restore,symlink,stream_socket_server,proc_nice,popen,proc_get_status,dl,pcntl_exec,pcntl_fork, pcntl_signal, pcntl_waitpid, pcntl_wexitstatus, pcntl_wifexited, pcntl_wifsignaled, pcntl_wifstopped, pcntl_wstopsig, pcntl_wtermsig, socket_accept, socket_bind, socket_connect, socket_create, socket_create_listen, socket_create_pair,link,register_shutdown_function,register_tick_function,create_function,passthru,p_open,proc_close,proc_get_status,proc_terminate, allow_url_fopen,allow_url_include,passthru,popen,stream_select
If you can't filter for these functions then a major component of security is missing.
Here are some examples of Remote Administration Tools (RATS) that will infect your site, through any vulnerable 3rd party module or site user account.
RATs can take many forms, some are easy to grep for:
<?php error_reporting(0); eval(gzuncompress(base64_decode('eF5Tcffxd3 ...
<?php preg_replace("/.*/e","\x65\x76\x61\x6C\x28\ ...
Some are more professional and obfuscated, and cannot really be grepped for, and cannot be found unless suhosin tips you off that they executed:
<?php $_0f4f6b="\x70\x72\x65\x67\x5f\x72\x65\x70\x6c\x61\x63\x65";$_0f4f6b("\x7 ...
<?php require "./.cache/.%D59C%49AA%73A8%63A1%9159%0441"; ?>
(note in this case the CACHE directory cannot be in source control, therefore cannot be tracked either)
IMHO, the statement above from duskwuff, that things would be fine without Suhosin is neither authoritative nor necessarily correct (especially given the amount of critical holes newer PHP versions have seen since then).
To my mind, it would be definitely better - from a security POV - if Suhosin was available for current PHP version.
Of course, as it is not, staying at old (eventually unmaintained) versions of PHP isn't a solution either.
Generally PHP and especially PHP applications are notoriously known for having security issues... so the question is less "are newer PHP versions safe without Suhosin"...
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.
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.