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 #1934498: Rollback the imagestyle 'itok' token, introduce a non-recursive option