2

I have read the security notices and understand that it "would allow an attacker to reinstall an existing Drupal site with an external database server and then execute custom PHP code". According to Drupal, "re-installation can only be successful if the site's settings.php file or sites directories are writeable by or owned by the webserver user."

I tried to Google for a better explanation as to how an attacker would exploit the install.php file but couldn't find any. I understand that there is a patch and a few quick fixes like the following;

<Files install.php>
  Order allow,deny
  ErrorDocument 403 "Access denied."
</Files>

But what I want to know it, What is the process to exploit DRUPAL-SA-CORE-2012-003?

(Would like a working example to be able to run on my test site)

Polynomial
  • 132,208
  • 43
  • 298
  • 379
Digital fire
  • 3,126
  • 5
  • 31
  • 44
  • Your `.htaccess` directive seems odd: why not use `deny from all` (with an optional `allow from your.developmen.ip.address`), rather than `order allow,deny`? More information: http://www.kavoir.com/2009/01/htaccess-deny-from-all-restrict-directory-access.html – msanford Oct 18 '12 at 15:42
  • http://oldwildissue.wordpress.com/2012/10/18/drupal-sa-core-2012-003-quick-fix/ – Digital fire Oct 18 '12 at 15:49

3 Answers3

4

I've checked the actual code and reproduced the exploit. In addition to all the conditions Polynomial mentioned, install.php must be called when the current database that is configured in settings.php is not available.

To exploit the vulnerability, attacker needs to somehow make a Denial of Service for the database server. For example, he can send multiple simultaneous requests to the site. These would connect to database, possibly reaching database limits (e.g. MySQL 'max_user_connections'). Within that narrow time window, attacker must start the new installation process (which would overwrite settings.php with attacker-chosen DB details).

Krzysztof Kotowicz
  • 4,068
  • 20
  • 30
2

It's quite a simple one, really. If install.php is accessible, and settings.php is writeable by the HTTP daemon (e.g. Apache), an attacker can simply go to install.php and re-install Drupal via the normal installation method. This overwrites settings.php and gives the attacker full access to your installation.

I haven't checked, but it may also drop and re-create all of the database tables, which is either a good or bad thing depending on how you look at it. It's good in the sense that the attacker would lose the credentials in the users table, and bad in the sense that it'd drop all of your data.

Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • I accepted as the answer because this was my first thought as well. But to me this doesn't seem like its a new vulnerability. Ever since Drupal 6, if you had your settings file writable. In the status report you would get a red flag. I have a feeling it may involved something else. But until I find evidence to state otherwise we'll go with this one. – Digital fire Oct 18 '12 at 18:31
2

There are multiple problems with the installer:

  • The installer can be reused when the database is down (not when up, as in Polynomials)
  • The installer can be reused on certain multisite configurations
  • The installer can be reused when the database is forced to error out when requests race to run the database tasks.

See also http://heine.familiedeelstra.com/drupal-7-installer-vulnerability

Heine
  • 106
  • 3