Has anybody forked PHP4 to continue support for this version?
EDIT: This isn't a question about migrating to PHP5.
As far as I know - no. PHP5 is pretty good with backwards compatibility and you should not run PHP4 on any publicly facing webserver if security is even a little bit important to you.
I would estimate that PHP5 is 99% backwards compatible. Here is a blog post with typical (small) issues you might run into, usually the way that functions behave in corner cases. Two other resources you might want to look at are Migrating from PHP 4 to PHP 5 in the PHP manual and the PHP5 Migration Appendix, particularly the backwards incompatible changes.
To sum it up: you will need to test in a detailed manner after migration. Most of the things will work, but some might fail in corner cases. Some things can be fixed by tweaking the php.ini, some need a few changes. In general, applications written for PHP4 are less secure than those written for PHP5, because some security features didn't exist or were not widely used. So something like mod_security or PHPIDS (or both) should also be considered.
There have been no known forks of PHP4 to continue its support.
PHP4's code is pretty large, and with all its extensions it would be a pretty large project to support as a legacy application.
Related
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"...
Back in the PHP 4 Jurassic Era, I often installed a PHP extension called 'eaccelerator' to boost the performance of PHP by caching the compiled byte code.
I've read elsewhere that with PHP 5, the need for add-ons like eaccelerator has decreased, but is there still enough of a speed difference to make it worth installing on Linux servers?
Yes, opcode caches still make a dramatic performance difference.
Most are using APC over eAccelerator these days, though.
No, eAccelerator is no longer actively maintained (as no evidence exists demonstrate it is).
I would say it's worth the effort to go forward with APC or another, more modern and actively maintained accelerator technology. If you are looking for OP code caching technology, go with APC, which is popular, has more library support, and is actively maintained. It will also apparently be included in a future PHP 6 release.
You might read this answer to another similar question, which suggests that eAccelerator may be viable if you take into account the deficiencies (probable lack of PHP 6 support, older and apparently unmaintained, etc.) and still want to use something you have a certain preexisting comfort level. It just depends on your needs and the environment you work in.
Would it make sense to switch to HipHop instead of XCache?
Is HipHop ready for primetime or should we wait several months before implementing it?
Edit: we are interesting in testing the configuration on a server running vBulletin.
Let me clear up a misconception you might have about Hiphop and Xcache. XCache works by adding Opcode caching to ZEND's PHP implementation (like APC and friends), while Facebook's HipHop allows for PHP code to be transformed into C++ code and then compiled using g++. It's not possible to run XCache with HipHop as HipHop doesn't depend on Zend interpreter (and doesn't even use php opcodes as it's compiled to bytecode after transformed to C++).
Now to answer your question, HipHop is being used live to host a large amount of Facebook's traffic. Facebook wouldn't release this project if it wasn't near stable, but since it is very new I would still exercise caution. HipHop is not just a patch to the old Zend Interpreter, it is a completely different way to run the PHP code and will probably have a few bugs in it.
One thing that Facebook did to ensure that Hiphop was working before they switched to it was they were able to setup very rigorous unit tests of each possible request on their site. That way if the output from Hiphop was different from the normal Zend PHP, they would go back and debug some more until everything "worked for them". Just because it "works" on Facebook code base doesn't prove that it'll work for yours. If you do decide to switch to HipHop, make sure to test it well.
EDIT:
HHVM (new VM version of HPHP) can now eval and create_function. They should be the same for all/most meaningful reasons.
There are a few things that aren't compatible with HipHop. They removed the eval and create_function functions. They also only support PHP 5.2.x for now, but they are plan to add support for 5.3 "soon".
I like the idea of HipHop, so don't get me wrong here, but there is something to remember: HipHop is not for everyone. From Sebastian Bergmann:
it is not a solution for a problem faced by 99.9% of the PHP deployments out there
Unless you have Facebook proportion traffic and your bottleneck is CPU or memory usage, you're not likely to see much of a benefit (as compared to xcache, apc, etc). Database and file system access are still going to be your killers.
I'm fairly confident that vbulletin 3.x will not work with HipHop. VB 3's plugin system consists of nearly 2000 eval statements sprinkled throughout the code, and eval is not supported by hiphop.
That's probably only the tip of the iceberg, when it comes to getting vbulletin to compile.
If I'm building a PHP system which I expect to port to many different servers, should I avoid relying on PHP 5 features such as exceptions and final methods? How widespread is PHP 5 by now? Should I be worried about compatibility and ditch exceptions and other features not available in PHP 4?
This depends on what type of servers that you expect to port to.
If you're looking at military contractors that are still using 486's because that's the last thing that was approved for shuttle missions, then, yes, you should use old software.
If you're considering hosted servers, the latest rev of whatever you're using will be available. If you are reselling a product to customers, you will be able to tell them what the system requirements are - OS, DB, scripting language and version, etc.
A lot of OSS fanboys will tell you two different arguments: avoid any proprietary extensions to anything because it harms portability, and 2) use the latest rev available. These are diametrically opposed points of view.
The reality is that in the web development world, I try not to let these types of debates keep me from developing using the best tools available. The one exception is browser compatibility, which is one thing that we don't have control over.
PHP4 is actually no longer supported. Only "old" distributions and installations will support it. All major Linux distributions only support PHP5 in their latest releases.
To still offer support for PHP4 would be a bad strategy for new applications.
It's definitely not a bad idea. PHP5 is much better than PHP4, it has better suport for OOP and references and it is available on the market for quite a long time. If you rely on PHP4 because of compatibility issues, then why not rely on PHP 1.0? ;)
BTW you can write portable code with version checks but in my opinion it is completely redundant at this time. PHP5 is a hard ground standard.
Should you ever run into somebody who wants the software to run on their PHP 4, the strongest argument is the support cycle. PHP4 is ten years old, and will not be supported very long any more (although I haven't been able to find out from the PHP web site how long exactly.)
The page at http://php.net/archive/2007.php clearly states that PHP 4 is no longer supported since august 2008. (Php 4 end of life announcement)
(look at the news published in 2008 to see the last maintenance release, published on august 7, 2008)
From the announcment in 2007, but certainly from the end of security support, I think new applications should no longer be developed for php 4, unless explicitly requested by the customer (allthough I would rather advice the customer to change his mind on that requirement). Keeping support for PHP 4 in older applications may be a bit different.