At the 19th July phpBB 2.0.17 had been released, which was just another security release. At the same time their development team proudly announced that they have started a audit of the complete source base together with a number of so called top-notch security people. They never wanted to elaborate the names of these people and therefore many people just believed that the audit did not exist at all and was only announced to stop hosters banning phpBB. Quite similiar to the sudden appearance of a certain inactive consortium after the Santy worm had been unleashed.

In the middle of August I had a look into the phpBB source code and found several weaknesses in phpBB that allowed to exploit a bunch of unitialised variables when register_globals is turned on (which is still the most often used setting). The problems I reported to them were several XSS, an SQL and even one remote code execution hole. While the whole impact of what I had found was not yet clear on the 14th of August it was the date of my initial report to the phpBB developers. This was obviously about 66 days ago.

From my point of view knowing about security holes, that can even allow remote code execution and that can be fixed by simply initialising a single variable for so many weeks, without releasing patches, is completely irresponsible. I surely can understand, that fixes need to be tested to ensure that nothing gets broken. But on 23th September I was told, that all security related patches are now given to the audit group to review and test them.

Because they obviously need more than 3 weeks to test all their security patches and because you can test the patches I sent them in a few hours, I am already prepared for the worst. They obviously have a very large amount of security patches that needs testing.

Who knows... Maybe the next reincarnation of Santy is not so far away...

Today Secunia has released an advisory about multiple XSS and include vulnerabilities in MySource 2.14.0. While this is not suprising, because MySource is just one more badly written PHP application, I was rolling on the floor after reading their solution.

The vendor has fixed the vulnerabilities in version 2.14.2 by warning 
the user during the installation process about the security risks of 
placing MySource script files in a publicly available folder and 
having "register_globals" enabled.

After a quick look into their installer, there is indeed a warning message saying:

It is important that the MySource path is *not* in a web-accessible 
location, as it poses a security risk. The 'register_globals' line 
in your PHP configuration (which can usually be found in /etc/php.ini)
must be set to 'Off' in order to provide greater security when handling
user-supplied input. An example ...

Of course they fail to mention that even if you have only the files they are speaking of in the document root directory, you are still vulnerable to the include vulnerabilities as long you do not switch off register_globals.

Well I just wonder how they will fix the code execution vulnerabilities that do not need register_globals turned on, if someone reports those to them...