Fix installer PHP code execution issues from SA-CORE-2012-003 (and backport anything to 7.x-dev as necessary)

In addition, the fix committed to Drupal 7 contains a known (minor) regression.

In the case of an advanced user trying to install Drupal via a preconfigured settings.php, if the settings.php is preconfigured incorrectly (e.g., wrong database credentials) or if the database server doesn't meet the requirements for Drupal to be installed, then starting in Drupal 7.16 we're now displaying a "Drupal already installed" message to the screen, which in most cases will be incorrect.

I felt this regression was acceptable, given the severity of the security issue (and the fact that's an edge case which only advanced users can ever encounter). Also, fixing it would likely involve introducing new translatable strings, which aren't a good idea to add in a security release since by definition they won't be translated in time for the release.

However, we should ideally fix this (now that we're able to discuss it in the public issue queue) and backport it to Drupal 7 in a future release. The fix would likely involve some kind of more ambiguous message (because in this scenario we really can't differentiate between Drupal already installed and settings.php being incorrect), but one that gives the administrator more of a clue what the error is... without exposing too much information to an anonymous user who may encounter this error on an already-installed site.

If that becomes too complicated, though, we can split it off to another issue.

Let's also tag this issue as a D7 release blocker, since although the original fix from Drupal 7.16 was merged in to 7.x-dev already, we want to double check that the latest 7.x code is not vulnerable before doing the next bugfix release of Drupal core.

(In this particular case, I think the chance is around 0% that this is the case, but I'm tagging it anyway to keep track of it and because in theory it is always a possibility due to differences between the previous stable release that the security release was made from, and the current code in 7.x-dev. Per the new release policy, we are now able to do this step in the public issue queue as a followup, rather than having it be part of the security team's private work.)

Trying that tag again...

@bhauff, so are you saying that before the installation, your databases array looks something like this?

$databases['secondary']['default'] = array(
  'driver' => ...,
  'database' => ....
  ...
);

But you don't want to pre-create the settings.php file itself? (Because if you pre-created the settings.php file itself, then for a particular site you could include the above as well as the standard $databases['default']['default'] in it all at the same time, and then you'd have no problem.)

I guess I can imagine that if your use case for this install profile is that it's only used on a particular server or set of servers, but you still want people to be able to install Drupal on their own, e.g. via the user interface... Kind of unusual, but I guess not out of the question.

One thing you might be able to do is wrap the above definition in something like if (!drupal_installation_attempted()), so that the secondary database doesn't become available until after the site is already installed (this assumes you don't actually need it while install.php is running).

It's also possible that the core patch was a bit too aggressive, and instead of checking !empty($GLOBALS['databases']) it could actually be changed to check !empty($GLOBALS['databases']['default']. I think that wouldn't have any security implications, but it would require a bit more thought to be sure.

I reviewed and tested the Drupal 8 patch, and it looks good. The same fix does work for Drupal 8 as Drupal 7, because although the surrounding Drupal 8 code has logic for verifying config directories in addition to the settings.php database connection, it turns out they are both done separately, so we'll always reach the block of code in the above patch when the settings.php file fails to verify.

I also double checked that the latest 7.x-dev code isn't subject to this vulnerability, so I'm removing that tag as well.

We still have some other things to follow up on from above, but none of them are critical so let's get this committed to Drupal 8 first.

There are no longer any security issues in 7.x here, so moving back to 8.x for possible followups discussed above - or it could be a separate issue but I don't have the energy to file one right now :)