When connecting to the database, if for any reason the connection cannot be established (wrong password, etc...) the system prints on screen much too much information that can be used by hackers gathering information.

The information includes the data base name, the user name, the full path to the script. The only thing missing is the password.

Here is an output example:

Warning: mysql_connect(): Access denied for user: 'xxxx@localhost' (Using password: YES) in /path/to/public_html/includes/database.mysql.inc on line 31
Access denied for user: 'xxxx@localhost' (Using password: YES)

Instead of that, the system should post a general error message, but should NOT disclose ANY of the information above.

Beginner.

Comments

killes@www.drop.org’s picture

killes@www.drop.org commented
Priority: Critical » Normal

Please enlighten me why this would be critical.

beginner’s picture

beginner commented
Priority: Normal » Critical

Any bug that compromises security, just like this one, should be considered as critical, no?

I am new with Drupal, and I was both very surprised and upset when I saw that it leaked such important information. From what I've seen done in other projects, the maintainers promptly release a patch when they find a full path disclosure bug like this.

beginner’s picture

beginner commented

Another full path disclosure error, seen when entering php in a test page:

Fatal error: Call to undefined function: array() in /full/path/to/public_html/includes/common.inc(1841) : eval()'d code on line 2

I'm afraid I'm only starting to notice them.
What's Drupal policy on security?

jayCampbell’s picture

jayCampbell commented

From http://www.sklar.com/page/article/owasp-top-ten

7. Error Handling Problems

If users (and attackers) can see the raw error messages returned from PHP, your database, or external programs, they can make educated guesses about how your system is organized and what software you use. These educated guesses make it easier for attackers to break into your system. Error messages shouldn't contain any descriptive system information. Tell PHP to put error messages in your server's error log instead of displaying them to a user with these configuration directives:

log_errors = On
display_errors = Off

See Also:

* PHP Manual: Error Handling and Logging Functions
* PHP Cookbook: Recipe 8.14 ("Hiding Error Messages from Users")

robertdouglass’s picture

robertdouglass commented

Wouldn't this be fixed by setting the Error reporting to Write errors to log on the admin/settings screen?

robertdouglass’s picture

robertdouglass commented

No - database connection problem - got it.

beginner’s picture

beginner commented

Thank you Jay for your information on Error Handling Problems.
(by the way, chap8 of the cookbook is availabel online, which includes Recipe 8.14 mentionned above:
http://www.oreilly.com/catalog/phpckbk/chapter/ch08.pdf )

The problem is that those:
log_errors = On
display_errors = Off
should be set in php.ini, which is possible only for those running their own server. Most of us are or collocation and can't possibly affect any of this.

Drupal itself should be able to handle this much more nicely:

if ($can_connect)
{
connect()
}
else
{
display ("generic error message");
log ("error to file")
}

With regard to message #3 above, the problem was that I entered some php code within a page (node), I made a silly mistake (I know, I should test at home first). I called a function that did not exist, resulting in the error message above.
The default for Drupal should always be to log such problems on file (or even on the database if accessible) and never allow such information to be displayed.

I would like to ask again:

What is Drupal's policy regarding security? Would a patch, or a security release be made available soon?

Thank you.

beginner’s picture

beginner commented

I have run into the very same problem, but under very different circumstances, so that I am quite worried about this issue.

The above disclosure happened when the DB access password changed but I forgot to update the config file accordingly. Stupid mistake.

On another occasion however, the data base couldn't be connected to and the same information as above was displayed to any user trying to access our site. What is very worrying is that up to today, I have no clue what happened: for a few hours, Drupal just couldn't connect to the DB. On the same site, I have a phpBB installation connecting to the same Data Base, and phpBB was working fine, so it was not a server or a MySQL issue. The site is still under development and there are only two of use regularly accessing the site. When I woke up one morning and found out the DB connect problem, I mailed the other admin to ask what changed had been made: none, apparently (the other admin only works on the html within pages). We exchanged a few mails, trying to figure out what had changed, and why phpBB could connect to the DB but Drupal couldn't (no config or other file had been modified). We were still pondering the question and we didn't touch anything when Drupal came back on line. As far as I am aware, Drupal went off on its own, and came back on on its own. Sure, there must be a logical explanation, but today, I still have no clue what it is.

This means that it could happen again anytime if the circumstances are repeated. It means that anytime, the same critical data could be exposed.

When is a patch released?

I am sorry that apparently Drupal's seemingly impressive security reccord may be due to the fact that the core developpers choose to ignore issues for which other projects quickly release a patch.

I still wonder why within Drupal nobody seem to think that a full path disclosure IS indeed a security issue. Other projects would promptly send a patch if one were found:
http://www.google.com/search?q=%22full+path+disclosure%22+security

http://sibowo.blogspot.com/2005/04/drupal-vs-wordpress-vs-postnuke-vs.html
Drupal record would look slightly less impressive if it had done likewise. On the pie chart in the document, I see entries for "Exposure system info" and "Exposure sensitive info". A full path exposure could fall under either. Drupal shows 0% advisories for both, but in the few weeks I have been using Drupal, I have found already two ways critical info can be exposed the other one being by inserting unvalid php within a page: stupid mistakes can happen, especially to beginners like me.)

And still, I cannot find a security policy document.

Steven’s picture

Steven commented
Priority: Critical » Normal

If disclosing the path compromises your security, you have much bigger problems to worry about. On most hosts, it is trivial to find or guess the paths of other accounts on the server. If you know they run Drupal, then you know their internal directory structure as well.

Secondly, the vaguer the message we output, the less we can help people who ask for support. If Drupal spits out a generic "Could not connect to database" message, we cannot distinguish those people who have not edited settings.php (it happens) from those who have, but are experiencing connection issues.

And I certainly agree that this is not critical. Critical issues are those that prevent your site from working, or which create a security /hole/. This is neither. It is the disclosue of information which some people consider to be private.

So, if one of them makes a patch, we'll review it and commit it if it is appropriate.

john.money’s picture

john.money commented

This is a pretty easily fixed... change the offending line 31 in database.mysql.inc as follows:

- $connection = mysql_connect($url['host'], $url['user'], $url['pass'], TRUE) or die(mysql_error());
+ $connection = mysql_connect($url['host'], $url['user'], $url['pass'], TRUE) or die('unable to establish database connection');

re: whether path disclosure is or is not a security risk, and whether this should be fixed is largely beside the point. If nothing else, it should be fixed on grounds of *site usability*.

Your site users don't want, don't need, and shouldn't see such errors messages. Half of them will think they caused the error. Another third will think your site is permanently broken. And if you're real lucky, 1/100th will report the error to you.

This issue also brings up the related topic of how should a site "fallback" if database connectivity is not present. For example, some of the settings I actually prefer to hardcode in the settings.php file. What I give up in UI flexibility I gain in usability if the database connection goes flaky.

beginner’s picture

beginner commented

Thank you Gestaltware,

I am not proficient enough with php that this kind of easy fix come to me naturally.

I am thinking to make the fix more admin/user/debugging friendly.

Now that you've told me where to look, I'll try to find the time to make it more friendly, by having a more explicit message displayed for the user, and write the debug message to file, server side, for the admin to pick up.

When I get to do it, I'll attach the patch here.

Thanks.

--
http://www.reuniting.info/
Healing with Sexual Relationships.

beginner’s picture

beginner commented
Assigned: Unassigned » beginner
killes@www.drop.org’s picture

killes@www.drop.org commented
Status: Active » Fixed

fixed in development version.

Anonymous’s picture

(not verified) commented
Anonymous’s picture

(not verified) commented
Anonymous’s picture

(not verified) commented
Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)