DeeEmm

Pragmatism in code

Waxing lyrical about life the universe and everything software related since lunchtime 2006.

Dolphin 7 Security Vulnerability Exposed

It would seem that this weekend has been an active time in the CMS community for security vulnerabilities, first Joomla issue a patch for a potential XSS issue, and now Boonex's Dolphin package has been raising some eyebrows with, an as yet unresolved security issue that exposes the database name, username and password, in plain text to the browser via a verbose error report. This report is triggered by any number of bugs, and could easily be used to compromise a website or server.

The security 'hole' had previously been reported and raised as an issue with the Dolphin developers, who's response was that it had been addressed. Amusingly this seems not to have been the case, with the latest attention being that the bug has now been witnessed on the Boonex admin test site, and the resulting full error report published. - http://www.boonex.com/unity/forums/topic/Hey-BoonEx-Notice-Something-.htm There is some further discussion in the blogs as well - Major Security Risk: Information and Temporary Solution

The community were quick to act, with a couple of suggested workarounds published on modmysite - http://www.modmysite.com/general-issues-comments-questions/10491-db_full_visual_processing.html#post39764 as well as on the Boonex site, but there has been no official response.

As of the time of this post, some three days after the original post, Boonex have still yet to comment, and there has been no official patch available to address the issue.

The security flaw raises the question of the validity of the security audits that were supposedly conducted on Dolphin 7 and 7.01 prior to release, and certainly brings into disrepute those that conducted it.

If you are currently running Dolphin 6 or 7 use the following instructions to address the issue (fix courtesy of Smoge at modmysite)

Below are instructions including what file to check, 
and what to change, to avoid this situation.
Dolphin 7.0.x (inc/classes/BxDolDb.php)
Dolphin 6.0.x and 6.1.x (inc/db.inc.php)

Look for the value, near the top of the file, like:

define( 'DB_FULL_VISUAL_PROCESSING', true );

It should be set to:
define( 'DB_FULL_VISUAL_PROCESSING', false );
Making this change will prevent users from seeing debug
information (some sensitive) in the event your site has
a database error.

/DM

Dolphin Orca Update
Joomla 1.5.18 Released

Related Posts

 

Comments 4

DeeEmm on Monday, 07 June 2010 03:15

As a bit of an update on this issue. It appears that the issues is being considered a non-issue as the latest release ships with these settings disabled. However, I have just had an issue with my site - where both settings were disabled and I still received an error message.

I will obviously be following this up on Boonex's site.

/DM

0
As a bit of an update on this issue. It appears that the issues is being considered a non-issue as the latest release ships with these settings disabled. However, I have just had an issue with my site - where both settings were disabled and I still received an error message.

I will obviously be following this up on Boonex's site.

/DM
DeeEmm on Monday, 07 June 2010 04:05

OK - here's my fix for this...

edit the following file

BxDolDB.php

find

if( DB_FULL_VISUAL_PROCESSING )

replace it with

/* if( DB_FULL_VISUAL_PROCESSING )

find

else
echo $out;


replace it with

else
echo $out;
*/



This comments out section of code responsible for generating the error report.

My guess is that there is some issue with the use of constants that is either unreliable or can be exploited. In the case of my site, at the time it happened, there was an attack of some sort happening - possibly to create this issue where the error report is displayed. I cannot confirm this at this time, but it seems very suspicious that the two events would be unrelated.

/DM

0
OK - here's my fix for this...

edit the following file

[b]BxDolDB.php[/b]

find

[b] if( DB_FULL_VISUAL_PROCESSING )[/b]

replace it with

[b]/* if( DB_FULL_VISUAL_PROCESSING )[/b]

find

[b] else
echo $out;[/b]

replace it with

[b] else
echo $out;
*/
[/b]


This comments out section of code responsible for generating the error report.

My guess is that there is some issue with the use of constants that is either unreliable or can be exploited. In the case of my site, at the time it happened, there was an attack of some sort happening - possibly to create this issue where the error report is displayed. I cannot confirm this at this time, but it seems very suspicious that the two events would be unrelated.

/DM
DeeEmm on Monday, 07 June 2010 11:41

OK The above fix is not the complete answer....

A better solution is this...

Comment out whole genMySQLErr function.

And add am echo''; statement instead to prevent the function throwing an error.

/DM

0
OK The above fix is not the complete answer....

A better solution is this...

Comment out whole genMySQLErr function.

And add am [b]echo'';[/b] statement instead to prevent the function throwing an error.

/DM
DeeEmm on Tuesday, 08 June 2010 00:39

UPDATE.

On further investigation it would seem that the main issue is that error_reporting is set to E_ALL in the header.inc.php file. This causes the contents of the debug backtrace to be dumped to screen - irrespective of whether DB_FULL_VISUAL_PROCESSING or DB_FULL_DEBUG_MODE are disabled.

I have reported this as a bug.

/DM

0
UPDATE.

On further investigation it would seem that the main issue is that error_reporting is set to E_ALL in the header.inc.php file. This causes the contents of the debug backtrace to be dumped to screen - irrespective of whether DB_FULL_VISUAL_PROCESSING or DB_FULL_DEBUG_MODE are disabled.

I have reported this as a bug.

/DM
Already Registered? Login Here
Guest
Thursday, 19 October 2017
If you'd like to register, please fill in the username, password and name fields.

Captcha Image