I was a little bit bored during the last days, so I had a few glimpses on phpMyAdmin's source code. I was able to find a design flaw, that again allows the inclusion of an arbitrary local file. Unlike the very bad experience with a bunch of vendors during the last months, it was a pleasure to work together with a vendor, that takes reported security holes seriously.
The result of my research is available at the usual place over at the Hardened-PHP Project.
Ohh well just as a sidenotice: You are of course not vulnerable to this vulnerability if you are running with our Hardening-Patch installed.
Update: The phpMyAdmin developers have also released a security notice, and placed a link to us in it. This is nice. Other vendors f.e. thanked us, by removing us from their "library of approved external(?) resources", after we disclosed holes in their stuff. (Well another explanation would be, that the person behind this just does not want to link to anything else, than his own commercial services).
From time to time people ask if it is possible to use the Hardening-Patch together with the IonCube Encoder or the ZendEncoder. I usually answer, that they should ask the IonCube support or the Zend support, to simply create compatible versions.
This will change in the future. I had a look at both encoders that are most probably the most famous ones and I am kinda shocked. The IonCube Encoder does not offer any protection against oparray_dumping or oparray disassembly. If you want to see this for yourself, then download derick and andrei's vld and apply the following patch: vle-request-hack.diff. After you have applied this, simply load the IonCube Loader as normal and activate vld as usual.
You will see the disassembly of the encoded PHP script in ZendEngine Opcodes and you will most probably not notice any obfuscation at all... (You can always compare the output to the output of the not encoded version)
The good news for all the users of ZendEncoder (or however it is called nowadays) is, that it is a little bit harder to get the disassembly of scripts that were encoded with ZendEncoder, because you will notice that the Opcodes are encrypted. But anyone skilled with runtime encryption layers will be able to decrypt those opcodes. When you have broken the opcode encryption they look like the output of ZendOptimizer. Which means there are some ZentOptimizer specific opcodes in it, that have something todo with cached functionnames...
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...
Yesterday several PHP blogs and news sites announced the launch of ning, which is the newest project of Marc Andreesen and is meant to be a playground for building and using social applications. These applications are implemented in a stripped down (or sandboxed) version of PHP and can be created by cloning or merging already existing ning applications or by directly writing them with their PHP API.
After hearing about this, my first thoughts were: interesting, crazy, brave...
After having a look at their acknowledgement page, which lists the names of several members of a certain consortium and a blogposting by their leader, where he claims to have provided PHP security consulting for ning, I was very curious to have a look at it...
I must admit that I was very amused after I had put "><script>alert("Obviously very well audited...");</script><blub into any of the input fields on the register and password forgotten pages. It seems that not a single field on their page is protected against XSS attacks and therefore it is wide open to password and cookie snatching attacks.
With such obvious holes left open on their main page, I seriously doubt it is a good idea, that they allow the execution of PHP code from within their ning applications.