Heine

  • Home
  • Drupal
  • About
Home

# 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.

  • Drupal
  • Security
  • Planet Drupal

Comments

Superman syndrome

Submitted by Matt Farina (not verified) on Tue, 2008/07/29 - 19:00

I'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:25

This 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:48

Heine, 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?

  1. Spread the word - think Drupal Tough Love, but aimed specifically at writing secure code. Give examples from the real world. Write about securely written modules, write about bad modules, write about actual vulnerabilities found in modules. And publish them on Drupal Planet.
  2. Enable good behavior - promote coder module. Extend coder module's secure code review capabilities.
  3. Expose bad behavior - start a security group on groups.drupal.org. Each member randomly picks 5 contributed modules, runs them through coder module, and publishes the results. Publish a top 10.
  4. Or even better: (adjust and) run coder module automatically on all contributed modules in cvs, and publish or email the results to the maintainers.

a few questions

Submitted by christefano (not verified) on Wed, 2008/07/30 - 03:09

Where 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:12

Any 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:07

This 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:06

As 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:32

Maybe 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:30

It 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:18

These 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:09

We 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:24

Thank 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:37

In 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.

Recent posts

  • Teampassword manager's password generator is biased
  • Other vectors for SA-CORE-2014-005?
  • Lazy loading: hook_hook_info is for hook owners only.
  • "Always offline" problem in EA's Origin due to antivirus
  • From bug to exploit - Bakery SSO
more

Security reviews

I provide security reviews of custom code, contributed modules, themes and entire sites via LimoenGroen.

Contact us for a quote.

Follow @ustima

Copyright © 2021 by Heine Deelstra. All rights reserved.

  • Home
  • Drupal
  • About