PHP - 15

Another small bug fix RC that hopefully brings us yet another step closer to the stable release.

Major Changes Include the following:

• Improved Invision Board conversion script, it now supports 1.3.X versions.
  


• Updates to the Russian translations.
  


• Improved search result format.
  


• Added the ability to generate a PDF archive of private messages.
  


• Added a script that simplifies the process of logging in a user into their FUDforum account from other applications.
  


• Multibyte handling for e-mails.
  


• Slight speed improvements and garbage collection.
  

This release can be downloaded here.

Here goes the first release candidate of the 2.6.12 release, this release includes a fair number of changes and improvements so much testing is needed to ensure everything is working correctly. Among the changes are massive updates and revisions to the Italian translation. Addition of support for non-ascii (htmlencoded) characters in login/alias names. Support for mass topic deletion/moving for administrators and moderators. Several performance improvements and various bug fixes.
The full scope of the changes can be found here.

The new release is available for download at: http://fudforum.org/download.php

GoDaddy has announced that they will be giving away 1 year Turbo SSL certificates to qualifying Open Source projects. To find if you are applicable visit their request form at:
https://www.godaddy.com/gdshop/ssl/ssl_opensource.asp

Seems like a neat idea that should give all OSS developers an opportunity to test their web applications with genuine SSL certificates and ensure that their applications work properly
over https.

A new stable release of FUDforum, 2.6.10 has been released today and is now available download. This release primarily is a a bug fix release with a number of low/medium priority fixes. All existing users of the forum are encouraged to upgrade to this release whenever possible. Full details of the changes can be found in the RC1 - RC3 release announcements on the support forum.

I am happy to announce that I will be speaking at the annual PHP Quebec Conference on March 31st and April 1st. I will be giving a talk on Web services and a workshop on the same topic. The conference includes talks by many great speakers on variety of topics and should be of interest to all PHP users.

I've been fortunate to be invited to speak at two conference so far this year.



The first of those two conferences, PHP West will be happening in about a week in Vancouver on January, 14th 2005. I will, be giving a talk on XML support in PHP 5. While the conference lasts only a single day it costs merely $40 to attend and given an impressive list of speakers Rasmus, John, Terry, etc... it is certainly worth attending.


The second conference, PHP|Tropics, is still a few month away will be happening at the all-inclusive (alcoholic drinks are included, WOOHOO!) Moon Palace Resort near Cancun, Mexico between May 11th and 15th, 2005. Which should give you plenty of time to convince your boss and/or spouse to let you attend. I will be giving a talk on making PHP run a whole lot faster as well as an introductory tutorial on PHP 5. Marco has been working hard at giving reason for people to stay away from the beach by inviting many other great speakers such as Wez, Derick, Marcus and many others. So aside from getting a nice suntan you'll definitely have a chance to learn about some of the neat things PHP can do. For even more reasons to attend visit the conference's website.

In response to the on going flame war pertaining to the stability and usability of Apache 2 in comparison to Apache 1 I've decided to conduct a series of benchmarks to try to determine exactly how the two Apaches compare. The purpose of the test was to determine which server is faster at serving static HTML pages, who's real-time compression implementation is better and of course which is more suited for running PHP applications. The full details of the test are available below, but here is a quick summary of the results.

1) Apache 2 is about 4% faster then Apache 1 at serving static pages.

2) Apache 2's mod_deflate is over 60 percent faster then Apache 1's mod_gzip at real time compression of static HTML pages.

3) Serving PHP via Apache 2 is 27 percent slower then via Apache 1 DSO and 31 percent slower then Apache 1 static. Continue reading "Apache 1 vs Apache 2 Performance"

As most of you hopefully know, a few days ago PHP 4.3.10 and 5.0.3 were released in response to several vulnerabilities that were discovered. Two of those involved bugs in unserialize function that is used to re-create PHP variables based on an encoded string normally generated by serialize() function. This functionality allows storage & retrieval of PHP variables from outside PHP.
While these two problems are quite serious, they can normally only be exploited locally, meaning that you'd need an account with access to PHP on the server. However, several applications such as phpBB store serialized data inside cookies meaning that anyone accessing those applications will be able to supply their own serialized string. By tinkering with this string it is possible to make an exploit capable of doing things like theft of passwords.

In response to this development phpBB developers decided to put the following statement out "This is not a phpBB exploit or problem, it's a PHP issue and thus can affect any PHP script which uses the noted functions".

First of all this is not a correct analysis of the situation, the only applications vulnerable are the ones that expose serialized data to the user allowing them to modify it, like phpBB does. Even if the bug in serialized code did not exist, there are still issues with exposing serialized data to the user without validation. There is nothing to prevent someone from generating a very complex data structure that would take long time to parse and use it as a means of launching a resource depletion attack. It also means that by modifying the serialized string it is possible to inject all manner of data into the script which may lead to exploits due to uninitialized variables, etc... Ultimately it comes down to blindly trusting the user with your data and expecting not to get penalized for it.

While unserialize is certainly a bug in PHP, the fact it is remotely exploitable is the fault of script writers who do not take the time to properly validate user input.

After what seems like months of development a new stable release of FUDforum, 2.6.9 is finally out. This release fixes a fair number of bugs as well as introducing a number of functionality changes. These include series of speed imporvenments for many parts of the forum as well as some optimizations aimed at MySQL 4.1 users specifically. As of 2.6.9 all installation are now capable of generating PDFs based on forum messages thanks to the customized FPFD library bundled with FUDforum. The layout of the PDFs was also improved. All FUDforum users are encouraged to upgrade to this release.

The upgrade and installation scripts can be found here.

Many PHP developers, myself included often mention that using PHP that is compiled statically (Apache module) is much (18-30%) faster then the shared module that is normally compiled. This is a rather unusual claim that is often met with much skepticism for a good reason, presense of pic code resulting from a shared build should not cause this, however benchmarks speaks for themselves.
Unfortunately finding hard data is rather hard since most of us are rather lazy to spend 30 mins performing the needed tests. Fortunately, George Schlossnagle published the benchmarks he conducted on the matter that conclusively demonstrate that the the static build is much faster.
The raw benchmark data can be found here Continue reading "PHP/Apache Static vs DSO"

This afternoon an interesting problem came to my attention. This problem is the result of PHP and mod_perl being used together on Apache server. The full details of the problem can be found here.
The quick summary is that if PHP code uses putenv() function it will conflict with mod_perl and cause frequent crashes. The suggested solution is to use the Apache's apache_setenv() function. However, as I found out this does not always work.
Continue reading "Timezone issues with PHP/mod_perl/Apache"

A few years ago PHP developers decided to address a problem not their's to solve by implementing a configuration directive called safe_mode. To those unfamiliar with this wondrous invention, this setting is primarily intended to provide file access limits to prevent users from accessing files that do no belong to them. This supposedly should make it impossible to access files of other people in a shared server environment, a common operating environment for PHP where PHP runs as an Apache module and as such has read access to all files accessible by the webserver regardless of the owner. When enabled, safe_mode will perform a uid/gid (user id and group id) check on the file/directory to be accessed and compare it to the uid/gid of the script that is trying to access the file. If the two match then the file operation will proceed as normal and in all other cases it will fail. In theory this is a fairly simple hack to a problem that is not otherwise easily addressed without significant performance penalties such as running PHP in CGI mode, whereby the scripts are executed under the user's own user/group id. However, as with virtually all hacks there tend to be unforeseen problems that further prove that temporary solutions only escalate problems. So let's examine the safe_mode problems and hopefuly demonstrate why it should be avoided. Continue reading "PHP's safe_mode or how not to implement security"

There are a number of tricks that you can use to squeeze the last bit of performance from your scripts. These tricks won't make your applications much faster, but can give you that little edge in performance you may be looking for. More importantly it may give you insight into how PHP internals works allowing you to write code that can be executed in more optimal fashion by the Zend Engine. Please keep in mind that these are not the 1st optimization you should perform. There are some far easier and more performance advantageous tricks, however once those are exhausted and you don't feel like turning to C, these maybe tricks you would want to consider. So, without further ado...
Continue reading "PHP Optimization Tricks"

Ever wonder what it takes to crash PHP, well here is a quick guide . Technically speaking PHP being a high level language should not crash, but reality speaks for itself. By knowing what could make PHP crash it may be possible to implement various safety mechanisms in your PHP configuration that would prevent users from crashing your PHP. This is quite important since a crash is not only a 'bad thing' [tm] in general but can also have several adverse affect on the web server potentially creating a possibility for a local DOS (Denial of Service). So without further ado here is the current crash list:

• Stack overflow. PHP does not have any internal stack protection choosing to rely upon the system stack without any protection. This means that if you have a recursive function or a method PHP will eventually crash.
  
  function a() { a(); } a();
  
  There are 2 solutions to this problem, 1 avoid using recursive functions they are generally a bad idea anyway, and if you MUST use them implement some counter using a global variable that would prevent the function from iterating itself more then X amount of time for values of X between 500 to 1000. The other solution involves using the xdebug extension that implements protection against stack overflows by defining a limit on how deep can recursive functions go via a php.ini value. This is a better solution in hosting environments where you have no control over the scripts that are being ran on the server.
  
  
• Bug inside the pack() function. This is not a terribly common function, however it is a part of the standard PHP distribution meaning that despite it's rare usage everyone has it and is vulnreable to it.
  The nature of the crash involves making PHP to try to allocate more memory then is generally avaliable on the system, when this happens PHP will immediately exit terminating the request or if you are using the debug build dump core and crash
  
  pack("d4294967297", 2);
  
  The only solution to this problem at this time to disable the pack function via the disable_functions php.ini directive and hopefuly non of your scripts or the scripts used by your users (hosting environment) use this functionality. Like I mentioned earlier this function is pretty rarely used so this is a more or less valid solution. Another solution is to enable memory_limit directive that would set the limit on the maximum amount of memory PHP script may use and when it tries to use more PHP will nicely terminate the request and not cause the termination of the child/process used to serve the request.
  
  
• Various header parsing vulnerabilities. Through a series of extensions PHP has the ability to work with images, these extensions include exif, GD, imagemagick, ext/standard's getimagesize(). To work with images PHP often needs to allocate various buffer to store the image data. The size of these buffers is determined by parsing the image header that contains this data. By modifying this data via the use of hexeditor or generating a bogus image header you can force PHP through those image extension to try to allocate more memory then avaliable or try to allocate invalid memory value such as -1 resulting in a crash.
  
  No example given since it would make it too easy to exploit, which is especially bad since many of these functions are often used to work on external images that web users can often specify. What it means that vulnerabilities of this nature have a potential of being exploited remotely.
  
  In most cases there are sufficient checks to prevent allocation of invalid memory sizes such as -1, so most common problem would be overallocation problem identical to the one in item #2. Just about the only solution other then the disabling of these extensions (fine solution if you don't use them) is to once again use memory_limit to prevent PHP from trying to allocate more memory then it should/can.
  
  
• Stack overflow in GD library that is exposed via the imagefilltoborder() function. The internals of this function rely on a recursive function call that given a certain type of image can result in a stack overflow.
  
  You can find an example of a crash script inside the ext/gd/tests/bug27582_2.phpt test.
  
  The solution to the problem would be to rewrite the GD library function that imagefilltoborder() is a wrapper of in such a way that the recursive function algorithm is not being used. Meanwhile the only fix to the problem is to use the disable_functions directive to prevent users from accessing this function.
  
  
• Forced over-allocation inside unserialize function.
  
  $a = "a";
  unserialize(str_replace('1', 2147483647, serialize($a)));
  
  Once we can 'force' PHP to try to allocate more memory then it can resulting in a request termination. The solution is once again to use memory_limit to allow PHP to handle the situation safely.
  
  
• Refcount overflow. In ZendEngine 1 the number of references to a particular variable is limited to 65535 because they are stored inside an unsigned short. This is something fixed in ZendEgine 2 where this value is stored inside an integer with a much greater capacity. However, since stable PHP is built against ZendEngine 1 this means that any PHP 4.X is vulnreable to this problem and what's even worse there is no easy solution.
  
  $t = array(1);
  while (1) {
  $a[] = &$t;
  }
  
  The only way to prevent this problem in PHP4 is to apply the following patch and rebuild your PHP. If you are using any external Zend or PHP modules those would need to be rebuilt as well. The only time you will not be able to do this if you are using binary modules that you cannot recompile because you do not have access to their source, such as PHPA, Zend extensions, etc...
  
  
  CODE:
  Index: zend.h
  ====================================
  RCS file: /repository/Zend/Attic/zend.h,v
  retrieving revision 1.164.2.21
  diff -u -3 -p -r1.164.2.21 zend.h
  --- zend.h      16 Mar 2004 17:36:17 -0000      1.164.2.21
  +++ zend.h      14 Apr 2004 18:01:37 -0000
  @@ -263,7 +263,7 @@ struct _zval_struct {
          zvalue_value value;             /* value */
          zend_uchar type;        /* active type */
          zend_uchar is_ref;
  -       zend_ushort refcount;
  +       int refcount;
   };
  
  
  
• Since the previous crash was specific to PHP4 let's have one specific to PHP5 to keep things fair. As you may know in PHP5 a number of extensions (SQlite, Tidy, etc...) implement native OO interface, which is very convenient, but has 1 problem. Due to the destruct order of externally loadable modules loaded via dl() function (deprecated btw) the module would be freed before the objects created by that module are freed. The end result is that when PHP tries to free the object the 'free' functions are no longer avaliable (they were inside the module) and PHP crashes.
  
  dl("sqlite.so");
  $db = new SqliteDatabase("foo");
  
  The solution to this problem is to either disable dl(), people should not be using it away, needed extensions should be loaded via PHP.ini or ensure that you manually destroy any objects created by that extensions by using unset().
  
  
• PCRE library bug. While this not a PHP bug per say since the cause of the bug is the bundled pcre library (non-bundled library suffers from the same problem) it still allows a PHP script to crash the process.
  
  preg_match('/(.(?!b))*/', str_repeat("a", 10000));
  
  There is no solution to this bug at this time, it is my hope that PCRE developers will consider this problem and implement a fix for it in the next release.
  
  
• Back to the old favorite, memory allocation. This time str_repeat() function allows us to very easily make PHP try to allocate excessive amount of memory and crash or exit when it fails to do so.
  
  str_repeat("a", 10000000000);
  
  The solution once again is to use memory_limit to allow PHP to handle the situation gracefully.
  
  
• The last way is not really a crash but still a very effective nastiness a disgruntled user can do on an Apache server.
  
  shell_exec("killall -11 httpd");
  
  As you can imagine this little command will result in the termination of all running apache children other the deamon that is running as root since all Apache children run under the same privilege meaning that 1 child could kill the rest. There are several protections against this, first of all make sure that the environment variable PATH for your webserver does not contain any dangerous paths, such as the ones containing kill & killall utilities. You can also disable execution commands by enabling safe_mode or using the disable_functions directive. The last solution is to run PHP as CGI or FastCGI where the processes would run under the same user as the one executing the script. This means that PHP script will not have permissions allowing it to kill Apache children.
  
  

There are a number of other crashes in PHP, some were fixed and some may still be present. However those tend to be inside obscure extensions that most people do not have enabled and as such are very unlikely. Other crashes while may still exist are in the process of being resolved, unlike the ones listed above that are likely to be around for quite a while.

Lately it seems that the possibility of PHP developers agreeing on something is about as likely as peace in the middle-east being declared overnight.
After about a two week cease fire, following the long and bloody fight about studlyCaps aka suckyCaps, which ended with a sound defeat of the forces of sanity & reason the PHP developer community is at it again. Once more we can thank John Coggeshall for this bit of entertainment, this time centered around wondrous PHP5 feature called "Exceptions".
As you may or may not know in PHP5 it is possible to throw exceptions, which you can then catch and theoretically through this process simply error checking process and make it easier to write code. John proposed that all error messages raised by OO code would report errors by throwing exceptions rather then using the current error reporting mechanism. Technically the idea is sound good, since it would allow reduction in the number of error checks, allowing all error tracking be performed via a single try {} catch () {} block around the relevant code.
Alas theory tends to neglect practical problems and this is where the fun begins. In PHP an uncaught exception leads to a fatal error resulting in the termination of the script regardless of criticality of the error that had occurred. Which means that if you god forbid neglect to put exception throwing code inside the block, your script will break and worse yet not provide any meaningful information other then you having an uncaught exception somewhere. More over some PHP errors can be ignored in many instances, these include NOTICES, WARNINGS and PHP5's STRICT errors, by making them exceptions you can no longer ignore them and must catch the thrown exception. This is particularly annoying for database extensions where there are numerous instances where it may be safe to allow certain operations to fail. In fact certain optimizations rely on trying to execute a query and upon failure execute an alternate query thereby avoid locking the table(s) used for for the operation, which has significant performance benefits. Even outside of the database world, having exceptions thrown on every error can do more harm then good.
Let's take the Tidy extension for example, which is first extension subject to this new exception treatment. Certain operations such as setting deprecated libtidy options results in harmless warning that can be safely ignored as it does not have any affects on the generated code. However, with exception a harmless warning becomes an exception that must be handled. Consequently the script author who intends to use the simpler OO interface will now pay for that simplicity with interest by having to implement various error handlers to ensure that his script is not terminated prematurely by an uncaught exception. What's even worse that once an exception is triggered the code goes directly to the exception handler skipping any of the latter code, meaning that you have very little choice but to terminate the script execution yourself after logging the warning or error. This pretty much the usefullness of exceptions, who's original goal is to simplify the error handling code.

Yet another proof that the road to hell is paved with good intentions.