iBlog - Ilia Alshanetsky

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.

A rather educational article came to my attention today reflecting the thoughts of some US citizens about Canada on public television in what one may consider to be major news outlets.
While I can only hope this is the opinion of a small minority, even that is a little alarming.

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"