It seems like this week is a bit of a strange one so far. Not only is it National Cyber Security Awareness Week here in Australia, but first the Boonex site suffered a massive DDOS attack and then my own dolphin site suffered a similar fate. I believe that the two events are probably coincidental, as the attack on my site was not particularly well formed, and was easily defeated - most likely just some kiddie with a script. I managed to get the service that the attack was coming from terminated due to a violation of the providers TOS - they're probably in big trouble with mom and dad now. The attack on the Boonex site continued over the weekend, and there are still some services out of action.

I believe that the main source of the attack on my site was to take advantage of the exploit recently published on Boonex's site, and reported about here on DeeEmm.com in an earlier news article - http://www.deeemm.com/news/154-dolphin-7-security-vulnerability-exposed.html Whilst the noise about this issue seems to have been muted a little, after the attack on my site I am pretty convinced that the solution given by Boonex is no solution at all.

The main crux of the problem was claimed to be the DB_FULL_VISUAL_PROCESSING or DB_FULL_DEBUG_MODE settings, which caused the debug backtrace to be echoed directly to the browser in the event of a fault. Boonex's comments were simply that these were disabled by default and so the issue was a non-issue. This glaring oversight caused an obvious embarrassment to those who made the claims that the issue was with the DB_FULL_VISUAL_PROCESSING setting, this then caused them to promptly back off a little.

Whilst Boonex's solution has seemingly pacified the masses, it does not address the initial issue - that the debug back-trace is getting echoed to the browser in some error situations. The fact is that the issue has been reported by many, and until now no one had been sure of a definite cause, unfortunately the DB_FULL_VISUAL_PROCESSING setting was little more than a red herring, and whilst easily dismissed by Boonex, their solution does not actually fix the issue.

The attack on my site was actually quite useful, as amongst other issues, it caused a permanent replication of this error, allowing me to test out a few ideas, and do a bit of investigative work. My findings are as follows.

Boonex employ the system function debug_backtrace() to generate their own backtrace, they then prevent their own backtrace from being echoed to the browser by the use of the DB_FULL_DEBUG_MODE setting. This however does not stop debug_backtrace() from dumping it's contents to the browser as it does this at a system level. Normally this is stopped by the server setting display_errors().

However - and this is the Killer - Boonex set the display_errors() directive to E_ALL in header.inc.php, basically overriding your server configuration so that it displays All Errors.

So, it seems that whilst there was a lot of noise, and some hasty decisions relating to DB_FULL_VISUAL_PROCESSING being the cause - there is still very much an issue that needs to be fixed.

Personally i have set display_errors() to zero in header.inc.php and commented out the Boonex code, and also commented out the entire code in the genMySQLErr function. I advise all to do the same.

/DM