When a Security Vulnerability is Just a Bug - Drupal Content Access XSS
If you pay close attention you may have noticed a recent disclosure of an XSS vulnerability in the Content Access module.
This report comes from a system administrator and security researcher at a fine university and contains a section titled Vendor Response:
Drupal security [team] was notified of this vulnerability on 5/19/2009. Vendor
has declined to issue an official security announcement due to the
restricted access rights required to carry out the proof of concept
exploit. Vendor has filed a bug with the module maintainer at
http://drupal.org/node/472494.
XSS is a big deal! With XSS you can run any activity like change a user's password. A similar issue exists in Drupal core.
However, the only way to exploit this vulnerability is to edit a role or create a new role, which is only possible for people with the permission to do a lot of other really bad things on the site much more directly than XSS.
The Drupal Security team has to balance the desire to have vulnerability-free code with the desire to get every end-user updated to the most recent code. If there are dozens of new vulnerability reports and releases of core/modules all the time end users will start to ignore them - particularly when they are for things like this which aren't the most important concern within this scenario.
Is that logic sound? Do we really have a noise/upgrade/"useless release" problem? Let's look at the numbers.
How quickly do Drupal site maintainers upgrade?
So, are we doing a good job of supporting people and getting them to upgrade their site and modules?
Sadly people are still very slow to upgrade. Screaming louder about security holes isn't going to help.
There are lots of things we can do here. I've heard complaints that upgrading is too hard - it's too easy to break your site in the process. I've also heard complaints that "Well, I upgraded and then 2 weeks later a new release came out. So now I wait 2 weeks after every release to make sure I only have to do it once." I've also heard "there are so many releases and I don't understand them, so I just upgrade my sites periodically."
Dang.
So, as bullet points of what we can do
- Make upgrading as easy as possible (without sacrificing security...)
- Reduce unnecessary noise and confusion around SA
- Only make an SA/Release when it's absolutely necessary
What else? Why don't you upgrade your sites? What could Drupal or the security team do to make you more likely to upgrade?
- Login to post comments
Comments
I'd like that you focus on
I'd like that you focus on your third bullet point.
I my own case, I do not upgrade quickly some websites because I don't have enough time and I'm alone to do that stuff; but for our purposes, lt's fine.
Update through the web page could be an interesting feature but I'm not sure that it's very secure.
update through the browser can be safe
This can be safe...if done properly. The Plugin manager does this in a safe manner, but is only for contrib, not core.
Charlie Gordon is working on this for core at Plugin Manager in Core
Clients have to approve.
Updating takes time. Albeit not much, but still. For my personal sites I don't really care, but for the sites I develop profesionally I have to request permission from my client and I of course have to bill them which they have to approve.
Security is a big deal, but if I mail them every two or three weeks that I need to perform upgrades, they simply say no. "It's working, leave it like that. Changes are slim we will be hacked."
I, of course, disagree with them, but in the end they are the ones who pay me.
Evaluate on a case-by-case basis
I read all security notices and only act on it immediately if it effects any of my sites. I read them, figure out what the vulnerability is, and if it doesn't effect a site, then I don't scramble to upgrade.
Not all vulnerabilities effect all websites. For example, many sites I work with involve only two roles: anonymous and administrator. I have yet to see a vulnerability open to an anonymous user. When all your authenticated users have access user 1's password, there aren't many security releases that effect you.
Consequences of exploits in a security release must be stated
It's just unreasonable in the current state of things to expect people to update every time there's a new release. I only maintain 15 or 20 websites, and it's way out of range for me.
Most of my websites have only anonymous users and a few trusted, known users.
If every point release of drupal said something like:
Exploits fixed by this release affect you if you have untrusted users with
Then I would pay attention to each release and evaluate it. But since I know that the majority of the releases are irrelevant to me, I just wait until the next time I'm working on the site to upgrade.
including this for a few months?
The announcements from the security team have included this for a few months.
When he announces them, Justin includes a list of mitigating factors that is similar in form.
Is there a specific recent announcement from the Drupal Security Team that you notice doesn't include this kind of information?
The release notes do not have any hints like this
I'm suggesting that the release notes, instead of screaming "YOU HAVE TO UPGRADE, RIGHT NOW", say
"You really need to upgrade right now if you have such and such a configuration."
The latest release note certainly has no information of this type. It just screams.
If you follow to the vulnerability description for 6.12, it's all security-ese, but there's no information about whether the risk affects me. Does it affect me if I have taxonomy turned off? I don't think so. Does it affect me if only trusted users can post content? Probably not. Does it affect me if anonymous users can post comments? I don't think so, but I don't see any clues here.
Most people won't/can't actually read the actual security advisory. But there could be a one-sentence statement in the Drupal point release notes saying who absolutely must update and why.
point taken
The release notes aren't meant to contain that information, but link to the deeper issues. If we pull up all the information from the linked issues it becomes "tldr."
Looking at that report, if you take the time to try to understand it, I think it's clear in these two sentences:
However, the language could be improved and it would be better if those were visually split into a "you're vulnerable if" section.
How does that sound?
"You're vulnerable if" would be a huge improvement
A simple "You're vulnerable if" section would be a fantastic improvement... Simple words in a prominent place. It would be best if they were both in the security advisory and the drupal release notes.
Automatic updates
A further issues, of course, is that we can't really get significant coverage on updates until there is some form of automatic update. It's just not going to happen, as much trouble as it is to update drupal. I know that volumes have been written on this, and it's a well-thought-out issue. But the day might come that only security issues were covered in the updates and bug fixes were addressed separately (mitigating some of the reliability risks associated with updates). And with automatic security updates life would be a lot simpler.
security update without bugfixes are available
That's the patch file. From the latest SA.
I was talking about automatic updates, with just the security
Yes, the security patch is available. But I was talking about an automatic simple way to add just the security fix to your site.
With any update, there are risks of breaking the site due to the change. Even the behemoth Microsoft breaks PCs with their automatic updates. There are probably two reasons that Drupal can't do automatic updates right now. The first is the actual security risks of doing it automatically, and the second is that automatic updates can break sites silently.
If Drupal updates were separated into security and bugfix updates, the risks of breaking sites would be lowered, I would think. And it would be rare that a db update would be required.
But I was really talking about automatic updates that included only the security fix. Patching is something that only the most dedicated techie will do, and then only when the techie has one or two sites to deal with.
Every upgrade should be one click.
I have one drupal site that I constantly am behind on my security updates. The problem for me is that it takes too long to do an update. It seems there could be an automatic, one click update system, or even (if the user chooses) an auto update system that implements the update proceedure? There is no way that I can do this more reliably than a script.
I really like the features of drupal, but for future sites I will probably use something else until there are easier upgrades.
Does someone have an existing project for one click updates for everything (or auto updates)? I don't think I am experienced enough of a coder to help much coding, but I would contribute some money, and I sure a lot of other people would too. I bet most people who want to use drupal, but don't like the security procedure would chip in $5.
other projects that use simple update
I use SugarCRM a FOSS customer management program that is web based. They use a one click update (ok about 3 clicks, but still)
the procedure is the web site has an update check,
links to the download,
you browse to the update,
the upload takes a xx.tar.gz file and processes it automatically.
updates anything and everything.
Only major releases need something more.
Drupal needs this type of update.