Entries from Ilia Alshanetsky

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"

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"

It would seem that good things come in two, this was proven yet again by the Postman who had delivered my two latest toys. These are the IDE to USB 2.0 adapter

and my USB 2.0 laptop hard-drive case


These Hong-Kong arrivals allow me to safely transport my 80 gig laptop drive, which has been "creatively" dubbed as the "Movie Drive". I am especially happy about this case as it does not require any external power, instead leeching off the needed power from my USB port which makes that much practical to use when I am on the road.

The IDE to USB is a welcome arrival as well, as it will finally let me make use (I don't know what for yet, but that does not matter ) the various IDE drives I got lying around the house/office.