Spellbook

At Halloween 2005 I had disclosed a number of bugs in phpBB, including a remote code execution exploit through the signature_bbcode_uid variable. You will not find this vulnerability in the phpBB security tracker because it is phpBB project’s practise to blame their bugs on PHP and/or otherwise downplay them or hide them. Unfortunately there is now a public exploit for this vulnerability, which was released yesterday while most of us were celebrating christmas.

Original post by blog-admin@nopiracy.de (Stefan Esser)

Today, started to test moving some of our PHP4 apps to PHP5.1.1. Some of this code was written for PHP 4.0.6, over 3 years ago. The migration so far has been relatively painless. Here are some of the problems we encountered.

• We use code generators a lot, and some of the generated PHP4 code gives us the infamous “Only variable references should be returned by reference” warning. This warning is because of a memory corruption problem that can occur in all versions of PHP (4 and 5 included). When we analysed the problem, we realised that the amount of code we would have to correct would be massive, so at the moment we are disabling these warnings by setting error_reporting(E_ALL-E_NOTICE). Not the correct solution perhaps, but given the size of our code-base, it’s a pragmatic one, as we have not crashed due to these memory corruptions in PHP4. If PHP5 starts to crash in weird places, then we’ll look into fixing this.
  For fresh PHP5 code we write, we do set error_reporting(E_ALL), and fix all notices. We do not use the E_STRICT compatibility check because of the ridiculous warnings that arise, such as the warning that the VAR statement is now obsolete; it isn’t, VAR will still be supported in PHP6, and this VAR warning will apparently go away in 6 too.
• Some of the oldest code continues to use the old super-globals format $HTTP_POST_VARS and $HTTP_GET_VARS. We had to enable in php.ini the setting register_long_arrays = On to set these variables.
• We use some PEAR libraries, and did encounter a few errors, mainly because we are using an older version. These were fixed by upgrading the relevant modules.
• Apart from these issues, it was a stroll in the park. Everything worked fine. Partly because the core libraries that we use (eg. ADOdb and phpLens) are continiously tested against the latest versions of PHP. The PHP Internals Developers did a really good job maintaining backward compatibility, though the number of E_NOTICE and E_STRICT warnings you get is too alarming…
• The main issue still preventing PHP 5 migration for us is the lack of a reliable open source opcode cache for Windows. Some customers use Unix, but others are more comfortable with Windows. I have hopes for eAccelerator, which apparently is in final beta.
• Once everything stabilises in PHP 5.1 and eAccelerator, I will get our software developers to look into setting up a parallel development environment on our Windows and Linux servers for both legacy PHP4 apps and newer PHP5 ones. And then I will start looking into creating a PHP5 version of the EasyWindows installer, a full-featured PHP installer for IIS that includes fast-cgi support.

Original post by PHP Everywhere - By John Lim