Monday, April 26, 2010

Full path disclosure bug in Drupal 6.16 (0day)


This time, we would like to share with you a few bugs ZeroDayScan found in default Drupal installation (Drupal 6.16). Both of these bugs lead to full path directory disclosure in the default Drupal installation.

Why it is important?

Full path directory disclosure bugs allow the attacker to study the internal structure of your website. It is very helpful in case SQL injection is found on the same box (and it also does not have to be on the same website that runs Drupal as most of the web servers host a bunch of websites). It happens because using SQL injection you can write files, and if you know the location of default Drupal installation, you can easily find the "files" Drupal directory. This directory is fully writeable as it is used as a temporary directory. As a result, an attacker can create a web shell on that box. For more information please check this article: Backdoor webserver using MySQL SQL Injection.

How to reproduce these bugs?

It is very easy. If the destination Drupal parameter is send not in a proper format, an error message is printed. To reproduce this bug, you just need to add the following path to your website's name: /node?destination[]=node . In our tests we use website. So we used the following URL:[]=node

Here is a an error message as we got it:

The following error is printed: warning: urlencode() expects parameter 1 to be string, array given in /var/www/drupal-6.16/includes/ on line 258. The bold text basically specifies where the Drupal files are located on the remote host.

Another bug is in the Drupal built-in login parameters validation mechanism. In order to reproduce it, specially crafted data must be sent to remote site. In our test we used the curl tool to do it for us. Here is a screenshot:

The following string is POSTed: name=aaaa&pass[]=Q1s2x3w4d&op=Log+in&form_id=user_login_block

The following error is printed: warning: mb_strlen() expects parameter 1 to be string, array given in /var/www/drupal-6.16/includes/ on line 404.

Any solution?

After contacting the Drupal security team, we learned that there is a workaround for this bug. It is recommended to configure Drupal to disable printing of errors to the screen (it is ON by default). You can do it by clicking on "Administer" >> "Error Reporting". Then select "Write errors to the log" instead of "Write errors to the log and to the screen". Here is a screenshot of this window:

We suppose that these bugs will be fixed in the next Drupal release. But we are not totally sure as the Drupal security team does not consider these bugs as high priority. No security alert is going to be released covering this issue.

Anything else?

Always update your software. Another recommendation, is to host each of your sites in a distinct virtual environment, so if one of the sites is vulnerable, it will not effect the other websites. Also consider installing the GreenSQL database firewall.

Finally, you should use the ZeroDayScan web security scanner to check your website and find Zero Day Bugs. It is a free tool and it really works and finds a lot of bugs including SQL injections. The ZeroDayScan security scanner found the bugs covered here. If you use custom modules in you Drupal installation, ZeroDayScan can check it and detect bugs.

Best regards,
ZeroDayScan team


  1. So if I summarize this: If you enable "display errors on screen", then Drupal shows errors on screen.
    whaw, you made a great discovery !

  2. For the records, the above disclosure was discussed publicly in the Drupal bug tracker at

  3. Hello Jo

    You do not need to enable "display errors on screen" because it is enabled by default.

    Drupal displays errors to screen by default.

    Hope this is clear now.

  4. Um... this is a feature.

    Drupal installs with errors written to the screen to help people debug any install problems. Before going into production, everyone should be turning this off:

  5. Also:

    "This [files] directory is fully writable as it is used as a temporary directory."

    That is not accurate. The files directory must be writable by the webserver, and ideally is not world-writable. It also is not used as a temp directory. Drupal explicitly uses an alternativel location for temporary file storage (usually /tmp like anything in linux, but sometimes elsewehere, and certainly not in the web-readable path).

    In a shared hosting environment under proper cgi or jailing, the files directory of your server is writable by you and no-one else (since that's who the webserver should run as). Even outside that scenario, a normal system user need not have permissions to write to the files directory.

    If you are making your files directory world-writable, its because your host isn't providing you with the right options for security, not because of anything in Drupal.

  6. Definitely a feature, not a bug. No Drupal installation is or could possibly be ready-to-go as soon as it is installed. Drupal is a framework; it requires configuration to make it do what you want it to. And if you're configuring things, you should be able to see where the problem is. Before you take your site live you can turn off the helpfulness.