Mitigation against CVE-2010-1584 Drupal Context Module XSS
Justin included information about mitigating factors:
In order to execute arbitrary script injection malicious users must have 'Administer blocks' permission.
Here are some more concrete steps for mitigation of this particular vulnerability.
1. Ensure only trusted roles have the "Administer Blocks" permission
My coworker Ben Jeavons wrote previously in this blog about the importance of understanding trusted and untrusted users on your site and how roles play in. We also built a check for some important permissions into the Security Review module that Ben built as part of his work with GVS.
To put it simply, while it's not on the list of roles that the Drupal Security Team considers to be site owning permissions that mean there is no need for a Security Advisory, "Administer blocks" is an important permission and shouldn't be given out to untrusted people who might
inject XSS into a block title reconfigure or disable all the blocks from the site.
Update: Heine Deelstra asked me to clarify that last line. In general, injecting XSS into a block title would merit an SA in the opinion of the Drupal Security Team. Granular permissions are a strength of Drupal and only permissions which allow for privilege escalation are included in the list we will not do an SA for.
2. Upgrade Context to the latest code from the repository
As often happens, the Drupal community can move quite quickly and in this case the issue has been fixed in the development version of code that exists in the source code repository. A big thanks goes to Steven Jones and to Young Hahn - two of the volunteer module maintainers - for helping out in this particular case . I say "volunteer" because Steven and Young are not paid by the Drupal Security Team to do this kind of work, though their employers may pay them for it, their employers are only one of many companies that benefit from the existence of the modules.
To get the code from CVS a site administrator could use this single command:
cvs -d:pserver:anonymous:email@example.com:/cvs/drupal-contrib checkout -d context-DRUPAL-6--2 -r DRUPAL-6--2 contributions/modules/context/
There is an issue to create a development snapshot release for this vulnerable branch so it would be easier to download the new code and that release will be created automatically by the Drupal packaging system within 12 hours.
Update: a new release has been created.
You should of course test an updated module in a test environment prior to releasing it onto a live site.
3. Disable the Context module
Only do this if you can't do steps 1 and 2. Really, both of those should be entirely possible and they are simpler.
The Context module provides a variety of features, but the most common one is a new way to show blocks on a site. So, if you can live without the features provided by context you can simply disable it.
Go to Administer > Site building > Modules and uncheck the checkbox next to the module and submit the form.
My personal commentary
My personal take on this is that it's been given a bit more hoopla than it deserves. The mitigation steps are simple and most sites would not be vulnerable in the first place. The Drupal Security Team has a policy of not creating "Security Advisories" in the case of Release Candidate (RC) software and, ideally, the broader world of "Security Researchers" would respect that.
Of course, it would also be ideal if site administrators respected the "developer" nature of these kinds of modules, but the project usage for Context shows that it is on well over 10,000 sites. Another solution to that would be for module developers to create official "1.0" releases of their modules if they are serious about letting them get used on lots of sites.
On a somewhat related note, the Verizon Security blog recently had a post about Security Researchers vs. Narcissistic Vulnerability Pimps.