# 8 on the Vendors with Most Vulnerability Disclosures list
Heine Tue, 2008/07/29 - 17:45
Every year Drupal tends to end up in a few Top 10s, making us happy and proud. The latest Top 10 we appear in is not something to gloat over however: The Top 10 vendors with the Most Vulnerability Disclosures (source: X-Force 2008 Mid-Year Trend Statistics). We are number 8, just after Cisco (7) and just before Wordpress (9) with being responsible for 1.2% of all tracked disclosures.
While the number of core vulnerabilities has been fairly constant over the last few years, the number of advisories regarding contributed modules has exploded. To illustrate; the first half of 2008 saw as many announcements as the entire year 2007.
Of course, the amount of disclosures does not accurately reflect the amount of vulnerabilities in a product (if we had not disclosed vulnerabilities in contributed modules, they would still be there), but the staggering amount of past vulnerabilities can lead to only one conclusion: this is not good.
Why so many vulnerabilities?
Here a few adhoc explanations for the increase in announcements:
- An explosive growth of the number of contributed modules.
- Better review: Drupal's profile increased; more outside interest in security.
- Bad quality modules.
When we go looking for bad quality modules, we consistently see a few types of problems in those modules: simple low-level issues (forgotten check_plain) and higher-order issues (properly using check_plain on the label of the little red button marked "Launch Nuke").
Clueless
Clueless authors simply do not know about the security features Drupal provides; they never use check_plain when inserting plaintext input in HTML, concatenate variables with SQL queries (heck some even use mysql_query) and have no problem using <form>s with $_POST.
Confused or Careless
Confused authors do not know (and do not check) what kind of input a function expects. They therefore check_plain the title argument to l(), or pass l() the output of t('...@var'). They check_plain the #options values for select elements, or the #default_value for textfield elements and forget to check_plain user-supplied data in the titles of checkboxes.
Gross negligence
These usually involve higher-order vulnerabilities but are still pretty braindead.
Some examples of actual vulnerabilities:
- Taking actions upon GET request.
- Allowing node saves/edits via webservices without providing an authentication mechanism or checking provided values for validity.
- Providing a way to call arbitrary functions with arbitrary parameters simply by accessing a URL.
- Dumping arbitrary database tables upon request.
What to do?
The clueless authors can and should be barred at the gate and through education get to know the Drupal way. I see an important role for the CVS account handling team to review code samples provided by new authors before they are granted a CVS account.
To stop authors from being confused we should better document what type of string a function or property expects.
We also need to instill a state of mind where a developer constantly wonders and investigates the security implications of every decision and every function written. I'm totally clueless myself on how we could do this.
If you have suggestions or want tell about the roadblocks you experienced while developing a secure module, please leave a comment.
Comments
Superman syndrome
Submitted by Matt Farina (not verified) on Tue, 2008/07/29 - 19:00I've herd it said more than once, it won't happen to me. I know a few people who don't attempt to follow security because they don't think their sites will get hit.
Another reason I commonly hear is that it's a pain to do and the developers are just lazy.
I've, recently, found a number of people developing drupal modules who don't really know how to develop. I give them a lot of credit for trying to learn but they aren't already developers and they can't find much teaching them how to do it. I couldn't find much either. And, after talking to a couple CS graduates who do web development, I learned a lot CS students aren't learning this stuff either.
Education...
Submitted by Matt (not verified) on Tue, 2008/07/29 - 20:25This is all about education of the developers.
Let's be honest - the documentation around Drupal is not very good, and finding out the proper security procedures is not easy. And security is hard to do, and very hard to do well.
I'm not sure what the solution is, but a great start would be peppering links to this page - Writing Secure Code - anywhere developers gather.
#8
Submitted by gaele (not verified) on Wed, 2008/07/30 - 00:48Heine, personally I read the news about the #8 position as: the Drupal security team is doing an awesome job!
But how to improve the situation?
a few questions
Submitted by christefano (not verified) on Wed, 2008/07/30 - 03:09Where would Drupal be on this list if the reported security vulnerabilities excluded contributed modules?
Do Joomla and WordPress also report vulnerabilities found in third-party software?
CPE
Submitted by Heine on Fri, 2008/08/01 - 02:12Any disclosure related to a wordpress plugin would fall under the wordpress 'vendor' if the plugin can be downloaded from the wordpress site. See http://cpe.mitre.org/specification/index.html.
Not a valid comparison.
Submitted by John (not verified) on Wed, 2008/07/30 - 06:07This list attempts to compare apples and oranges. Over 2000 different projects fall under the "Drupal" umbrella. Is every Windows application included in the "Microsoft" group?
Our wares
Submitted by Heine on Fri, 2008/08/01 - 02:06As we are distrubuting these modules from Drupal.org and people need modules for functionality not in core, I think we should take ownership of the problem and find a way to solve / minimize it.
Matter of perspective.
Submitted by xamox (not verified) on Wed, 2008/07/30 - 12:32Maybe this could be viewed in another sense, that we have a good security team that keeps drupal in check. I guess that maybe the vunerabilities may not be disclosed and then you have holes in sites without fixes.
Keep up the good work and the watchful eye on drupal. Security is the weakest link on any website, I would rather have a site down vs. someone stealing private data off them.
Thank you and some ideas
Submitted by alex_b (not verified) on Wed, 2008/07/30 - 13:30It actually makes me feel good that Drupal's in this list. That's partly due to the security team doing a great job in an environment that you described in your article. Thank you for this work.
Yet, I get where you're going at. Many of the security disclosures wouldn't happen if they didn't exist in the first place.
Could http://drupal.org/writing-secure-code need an update?
And could the link to this page from http://drupal.org/node/508 "Module developer's guide" be on a more prominent place?
In addition, could there be a standard letter with important instructions that new CVS account holders receive?
For my personal immediate action: We're having Drupal Lab in DC tonight. We will talk about security there.
Talk & culture
Submitted by Heine on Fri, 2008/08/01 - 02:18These are all good suggestions, and I'm especially interested in the observations you gained from the DC Drupal Lab. Is security ('proper programming') a subject on people's minds? Was it an eye-opener for some folks?
From our chat at Drupal Lab DC
Submitted by alex_b (not verified) on Fri, 2008/08/08 - 14:09We chatted about this, for the record:
People at the Drupal Lab (our hands-on meetup) in DC are very curious about Security. Clearly, to a good many of them the security related handbook pages on Drupal.org were new. In my short presentation I also pointed also to your blog post here as I feel it transports well the urgency of the matter while showing that taking care of basic security standards isn't rocket science.
I will keep talking about this issue here and I'll make a point in actually more asking about how people deal with security in their software projects.
Loosely related: Is this a book you would recommend? To what type of person?
http://phpsecurity.org/
Thanks
Submitted by Heine on Sun, 2008/08/10 - 02:24Thank you for the follow-up.
I do not know the book, but the sample chapters seem to be a bit weak and even confusing. There does not seem to be a unifying look at the issues faced by Web Developers.
Innocent Code: A Security Wake-Up Call for Web Programmers is said to be a good choice for any Web Developer, regardless of language. I have not read that either (shame on me).
Of course, while these books present the important issues, they are not specifically tailored to the functions Drupal uses. Greg Knaddison from Growing Venture Solutions is busy writing a book on Drupal security for, as I understood, a mixed audience. It should be out somewhere at the end of 2008.
We'll see how we can improve the documentation and its visibility as well.
Drupal Insecurity
Submitted by Justin Klein Keane (not verified) on Fri, 2009/03/06 - 15:37In my work at a higher ed institution I field a lot of calls from other orgs within my Uni as well as from other higher ed institutions. Many of them are seeking ways to implement Drupal and most, inevitably turn to Drupal security. Many point out the large number of reported security vulnerabilities and wonder if Drupal is "safe." I respond in a couple of ways.
First, I point out that a reported vulnerability is a good thing, it means that there are lots of people actively reviewing code and finding flaws. I also point out that in general, Drupal is very responsive to vulnerability disclosures and problems get fixed quickly. It is problematic that users must task someone with monitoring Drupal announcements and perform upgrades on a somewhat regular bassis, but it's better than being exploited via undisclosed vulnerabilities.
I also like to point out that Drupal core accounts for only a very small portion of security flaws. At my institution we keep a list of "approved" modules, or third party modules that our staff have reviewed and didn't find any flaws in (I emphasize that this isn't a guarantee that the modules are safe, just that they've been reviewed). We share this list and lots of contacts feel relieved by this notion and use only modules that we've vetted for security.
Perhaps if the Drupal security team were to "certify" certain modules that might reduce the number of reported security flaws (as the security team would find them proactively) and also assure customers that as long as they were using Drupal core and certified modules that their chances of being exposed to a security issue would be reduced.