Heine

  • home
  • drupal
  • drupal core commits
  • about
Home › Drupal

ZeroDayScan - Full path disclosure bug in Drupal 6.16 (0day)

Heine — Wed, 28/04/2010 - 21:01

We recently received a report by "ZeroDayScan", about a "Full path disclosure bug in Drupal 6.16".

You can read the story @ http://blog.zerodayscan.com/2010/04/full-path-disclosure-bug-in-drupal-6.... As my short comment was removed from the post, I have to resort to a blogpost. My apologies for polluting the Planet.

Summary of the issue: If you set error reporting to the default value "Write errors to the log and to the screen", the installation path is displayed on the ...*drumroll*... screen.

Which is of course the point.

Calling the setting a "workaround", the default a "bug" and a "vulnerability" is either idiocy, or insincere. Now that comments were removed, we know. Insincere and at the same time a great way to highlight the impotence of the ZeroDayScan scanner.

My last message to ZeroDayScan: If there's an SQL injection on a Drupal site; you can simply take over the site as uid 1 (root); no need to find out the full path via an obscure error message.

Average: 4 (8 votes)
  • Clowns
  • Drupal
  • Planet Drupal
  • Security
  • Login or register to post comments

(x-posted to the issue:

entendu (not verified) — Wed, 28/04/2010 - 23:00

(x-posted to the issue: http://drupal.org/node/783618#comment-2903794)

I think the point here is that Drupal reveals its path to all users (including anon) in errors by default. Should that be the case? Sane defaults are obviously something we should be reaching for, so the question is: is this sane?

Perhaps a saner set of selections for Drupal error reporting would be:
-Log to database only (recommended for production)
-Log to screen and database (recommended for development)
-Log to screen only for User 1, and always to database (default)

  • Login or register to post comments

As I commented on the issue,

Heine — Wed, 28/04/2010 - 23:12

As I commented on the issue, hiding errors from Anon users is not very helpful in the dev stage of the site. What if you encounter an error during / before login or when installing?

The less savvy user will be stuck and will be left with very little information to use for Troubleshooting.

  • Login or register to post comments

Master switch development / production

George Moses (not verified) — Thu, 29/04/2010 - 08:51

There could be a "master switch" in Drupal, which could switch the site from the development phase to production and vice versa.

With the switch all kinds of settings could be changed:

  • Error reporting
  • Enablement of devel or testing modules
  • Debug info
  • Caching / optimisation settings
  • Misc security settings
  • etc..

Ideal for the "less savvy" user and more secure / better performance for Drupal in general.

  • Login or register to post comments

Recent posts

  • Unserializing user-supplied data, a bad idea
  • Planet Drupal past and current
  • Help! - Cannot access a global variable.
  • Why is my module's update hook not listed on update.php's selection form?
  • How do I add a class to a link generated with l()
more

Security reviews

  • Afraid custom code makes your site vulnerable?
  • You don't really trust that module you just downloaded from Drupal.org?

Sleep better after a security review.

Tags

Captcha CSRF Drupal embed Input Format modx OpenID Performance Planet Drupal rants Security Varnish
more tags
  • home
  • drupal
  • drupal core commits
  • about

Copyright © 2010 by Heine Deelstra. All rights reserved.