Mitigation against CVE-2010-1584 Drupal Context Module XSS
Recently Justin Klein Keane posted information about a vulnerability in the Context Module for Drupal.
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 protected]:/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.
- Login to post comments
Comments
Don't hate
Been pimpin' since pimpin' been pimp
^ don't being pimpers if just
^ don't being pimpers if just got pimped
the pimp thing
The whole pimp comment is quite disturbing. I told Drupal security about this problem weeks before disclosure. Then, when told Drupal sec didn't do SA's for RC I asked for confirmation and waited a few more days. After all, the White House uses this module. You seem to insinuate that my motivations are narcissistic, but I get absolutely jack shit from putting my name on these disclosures. Actually, check that, I do get derission and harassment. All of it does serve as a good motivator to turn researchers away from responsible disclosure. I do my best to work with Drupal security and get very little but grief for my efforts.
multiple perspectives on the issue
I didn't call you a pimp. I said it was somewhat related to the situation. Don't overblow what I said.
In my opinion there are at least two individuals who are potentially acting like the "NVP" described in that post.
The Reg article calls this a "Gaping" hole. Gaping means "wide open" and there's nothing gaping about it. Using that word and the information about 10,000 sites to imply a widespread exploitable hole is strictly for shock value.
I feel disappointed that more of my advice wasn't included in the article. I explained that the hole is somewhat obvious when looked at from the code side and not from a black-box penetration side and, afaik, the White House did penetration tests and not necessarily code level analysis. Their particular configuration prevents this from being exploited at multiple levels including within Drupal. Stating otherwise ("gaping" meaning open) is insincere when I had explained the review process and some of the security features in place that prevent exploit.
There is of course concern, though no clear evidence, that the Reg article tip-off and their anonymous security researcher are you, Justin. And that would feel pretty clearly like a NVP. Without having certainty that it was you I left it as something to consider in the context of modern security research. I feel the labels used for researchers are a timely topic worth discussing even if the potential association grates on your nerves.
If in fact you get "jack shit" from doing these disclosures why do you include them on your blog and include your name on them when you send them to fulldisclosure? And why is the first thing in those e-mails to fulldisclosure a link back to your blog? From an information architecture perspective the first thing in the e-mail is the most important thing - you've shown that the most important thing to you is that link to your blog...
I was unaware of this
I was unaware of this security issue and will look over the administrator blocks permissions right away. I thank Justin for not only finding this vulnerability but for posting the fix for it as well. Kudos!
Jason