Voting starts in March for the Drupal Association Board election.
When the 'image_allow_insecure_derivatives' config setting is enabled, sites are still vulnerable to DoS attacks when a derivative of a style is requested.
This issue has been fixed in D7 and tests have been added but this has not happened in D8 yet, which means sites with this setting enabled are a lot less secure than in D7.
Disallow requesting derivatives of image styles, even with the 'image_allow_insecure_derivatives' config setting enabled. Drupal 7 tests were added in http://drupalcode.org/project/drupal.git/commit/33d91c4, forward-port those to Drupal 8.
Alternatively, consider removing the feature.
User interface changes
Just like in D7 we always require a token when a derivative of an image style is requested
Data model changes
For background, see http://drupal.org/drupal-7.20-release-notes.
Because Drupal 7.20 fixed a security issue that was related to fundamental functionality in the Drupal core Image module, it broke a fair number of contributed modules and custom code/workflows. Because of that, many sites which have tried to upgrade to Drupal 7.20 have been unable to, or have upgraded but have set the 'image_allow_insecure_derivatives' variable to TRUE. In either case, these sites are completely unprotected from the denial-of-service issues that Drupal 7.20 was designed to fix.
This patch is designed to provide some level of protection even to sites that use 'image_allow_insecure_derivatives'. They will still be vulnerable to some kinds of denial-of-service attacks using image styles. However, the most damaging and easiest-to-inflict attacks (involving the generation of derivatives-of-derivatives, as well as the unauthorized creation of empty image style directories) will be protected against. Thus, although the variable is still considered insecure and is not recommended, it will allow sites using it to upgrade to Drupal 7.21 and at least have some security protection, while they wait for the other fixes they need to be able to stop using it altogether.
Some details of the above attacks have not been publicly disclosed yet (or have been partially disclosed elsewhere on the Internet), but the Drupal security team has cleared this for public discussion because it's not really fixing any new security issues; they were all already fixed in Drupal 7.20 for sites not using the bypass variable, and the bypass variable was already documented as insecure.
My plan for this patch:
- Commit it as soon as possible, unless someone finds something really wrong with it.
- Release Drupal 7.21 on top of Drupal 7.20 (containing only this fix). Hopefully tomorrow.
- Move the issue to Drupal 8 and forward-port it (as if it were a security release). Tests would be added at that point (and could then be backported to Drupal 7). Tests should likely involve checking that (a) even if 'image_allow_insecure_derivatives' is set to TRUE, it is still impossible to visit a URL which creates an image derivative based off an another image derivative (unless the URL contains the security token), and (b) even if 'image_allow_insecure_derivatives' is set to TRUE, it is impossible to visit a URL which creates an arbitrary empty directory in the site's image styles directory.
Follow-up could be