by Nate Haug on June 4, 2008 // Short URL

The Open Security Model, Drupal and ExpressionEngine on Security

I recently evaluated ExpressionEngine for viability as a CMS replacement for Drupal. ExpressionEngine (EE) is a commercial CMS tool built on PHP and mySQL by EllisLab. A client of ours was attracted to its clean interface, built-in features, and expandability.

I was impressed by the well-designed UI and the flexibility of EE's templating engine. There are definitely lessons the Drupal community can learn from their attention to detail. In fact, as I explored the EE support forums, I discovered a great deal of antagonism towards Drupal -- to my surprise, it wasn't based on features or learning curve, but on the idea that Drupal is insecure.

In the forums, comments such as this were common whenever Drupal or other CMS systems were brought up for comparison:

Some reasons why one might not want to use Drupal?

[2/5] Drupal Acidfree Module “node titles” SQL Injection Vulnerability
[2/5] Drupal Unspecified Spoofing Weakness and Cross-Site Scripting
[2/5] Drupal Project Issue Tracking Module Multiple Vulnerabilities
[2/5] Drupal Project Module Script Insertion Vulnerability
[4/5] Drupal Comment Preview Arbitrary Code Execution
[1/5] Drupal Textimage Module Security Bypass
[1/5] Drupal Captcha Module Security Bypass

And that’s just for the month of January. RonnieMc has pointed out before, however, that this might actually be a factor to choose Drupal as it presents job security--constantly keeping up with vulnerabilities and updates to all of your components can be a full time job.

All the links above reference Secunia a reporting service that aggregates reported issues on security. By doing a few searches, you can view the Secunia security issues reported for Drupal and ExpressionEngine.

Performing the above searches, you can see that ExpressionEngine has had only one security advisory over the course of 3 years. Over that same time period, Drupal has had over 80. It's easy to draw the incorrect conclusion there that ExpressionEngine therefore is more secure. Secunia specifically states "The statistics provided should NOT be used to compare the overall security of products against one another." And for good reason, what we're experiencing here is a difference in security practices. In this particular difference, Drupal reports its security vulnerabilities, while ExpressionEngine does not.

At the time of initial research however, it was not clear that this was the case. With the primary developers touting the security of ExpressionEngine over Drupal, I thought perhaps EE does have much better security. So I set out to see what happens when security issues are reported.

Finding ExpressionEngine Exploits

In one day of evaluation, I found 3 security vulnerabilities in version 1.6.2 of the core ExpressionEngine software (at that time, the latest version). That didn't bode well for my expectations of EllisLabs' reporting of issues. The vulnerabilities included a simple XSS attack, unauthorized deletion of private message files, and allowing of arbitrary code execution (dangerous enough that I e-mailed the developers directly). Unsurprisingly, none of these issues were reported to Secunia.

Executing PHP on EE
Running PHP on the http://demo.expressionengine.com demo installation. ExpressionEngine allows and executes image files that contain PHP code.

The code review of ExpressionEngine revealed a very high awareness of secure exploits, and took steps to avoid many forms of attacks. There are several functions built-in that scour uploaded files for potential embedded code, and inline documentation that mentions why certain precautions are taken. ExpressionEngine in itself is a fairly securely written piece of software.

What's different between Drupal and ExpressionEngine is how each responds to security vulnerabilities. Despite efforts to write secure code, programmers invariably make mistakes. How those mistakes are handled determines a large part of how secure the software is overall, but more importantly how secure the sites are that run the software.

Drupal Approach - Announced release

Drupal believes in an open security policy. Because all the source code is available at all times, attempting to cover-up security problems by discreetly slipping it into an update isn't viable, because all the changes between versions can be tracked. The fixing of the bug usually happens through a special security process, where the security team is notified via e-mail. The problem is fixed in the source code, then an announcement is made as quickly as possible that an update needs to be applied. This explains the 80+ vulnerabilities listed by Secunia on Drupal, because every security problem is handled in a public manner. Websites running insecure versions of modules are notified via the Update Status module, strongly encouraging administrators to update the module as soon as possible.

ExpressionEngine Approach - Quiet release

EllisLab takes the opposite approach, instead attempting to correct security problems without publicizing their errors. In the case of the 3 vulnerabilities reported from the security review, no warning was ever issued to their clients of potential vulnerabilities. A new release was created and posted to the download area, and sites that are running the previous version of the software receive a notice that a new version has been released.

After the new version was released, I finally was able to see exactly how a serious vulnerability was handled. In the ExpressionEngine changelog, the vulnerability that potentially allows total control of a site was summarized in a bullet point:

Increased security with uploaded file names to prevent Apache from overzealously parsing a file as a script.

It would stand to reason then, that the phrases for "increased security" or "add additional security" truly mean "fixing a security problem". The publicly available changelog lists at least 14 enhancements of security, each one likely fixing an actual security problem. In these cases, ExpressionEngine is leading their customers into a false sense of security. Claiming a high level of security publicly while quietly fixing easily exploited bugs during development.

Open Source, Open Security

There's nothing wrong with discreetly fixing bugs. Doing so can make it more difficult to find the exact exploit. However, in the case where users can easily compare one version against another, the manner in which the bug is fixed is a small barrier for hackers. Because most web applications are delivered in a parsable scripting language (such as Perl, Python, PHP, JavaScript, ASP, etc.) the full source code of these applications is available to anyone that has ever installed the software. It only takes a single, well-informed user (hacker) to read through the code, and expose potential threats. The "security by obscurity" approach, while always dangerous, has even less effectiveness when the source code is available.

So to the folks at ExpressionEngine, yes, keeping your software secure can indeed be a full-time job. Because mistakes are inevitable in coding, security problems will exist in all software. Simply not telling the software's users about insecurities won't keep hackers from exploiting them. It's a matter of educating, that the best way to have a secure website is to have an up-to-date website. ExpressionEngine is serious about fixing problems, so long as they don't have to tell anyone. With their current marketing spin on security, the most difficult task will be honesty with those users that have been mislead.

Nate Haug

Senior Drupal Architect

Want Nate Haug to speak at your event? Contact us with the details and we’ll be in touch soon.

Comments

GSO

Open is the only way.

Nate you wrote a very nice article, and definitely drove the point home that an open policy that encourages testing always prevails. I am looking forward to more articles written by you regarding security. I posted your article on our main page GovernmentSecurity.org

Reply

EclipseGc

Very well handled

I actually have friends who work for EE, so I'm hoping to paste them this article shortly, and I really admire how gently you handled the topic. Very diplomatic.

One of my old websites used to run on pmachine (before I converted it to Drupal) so I have a bit of experience. EE was the primary competitor internally for us using Drupal, but ultimately, we made the right choice and went the Drupal route. Open Source is just too important to ignore.

Kris Vanderwater

P.S. That old site is http://www.swagonline.net

Reply

Yuval Hager

Brilliant

Nate,

This is a brilliant article. You've definitely done great work in revealing those security issues, but you didn't stop there. You reported and looked to see how it is handled.
You definitely made a point, and a very clever one indeed.

Reading your post by hyperlinking to EE forums did get me quite worried as I continued to read there (should I move to EE?, I was wondering to myself..), but then, I went back to your post, and as I continued to read, a big smile slowly took over..

Thank you for increasing the faith in Drupal and it's open (security) model, in which I truly believe and am proud to be part of.

Reply

angie

Another thing worth noting about the referenced security alerts

Out of the 7 issues listed there, *one* is about a bug in Drupal core. The rest are around some of its community-contributed modules, most of which are only used by a handful of sites.

In this case, finding more security notices out there is a *feature*, not a bug. Drupal's security team is not only looking after the security of Drupal itself (which has many eyes on it and each commit goes through rigorous peer review), but also the security of all of the community-contributed code out there that extends Drupal. Where in another project, you might download some extension or theme off some random site and install it, never to go back there again to learn about the gaping security flaw that was fixed in version 1.2, Drupal goes out of its way to warn you when your extensions have had flaws discovered and new releases are available.

Drupal's security team also takes every potential threat very seriously. It's a potential XSS vulnerability in Foo module that only takes effect if you have Bar, Baz, and Noodle modules installed, you have a certain variable configured this way, you're using this particular version of Apache, and the moon's in its third phase? We'll make a security announcement about it, and a new release that fixes it. XSS threats would never be "glossed over," and something as critical as a remote code execution exploit would be plastered all over the place, not limited to a single bullet-point in a changelog.

I know which method makes me feel more secure, as a user, and as a developer.

Reply

Anonymous

Great except you leave out the part...

That if you specifically outline exactly what a exploit might be, or is, they you also directly affect people running versions before they can be upgraded or corrected. So yes, there are pro's to an "open security" model but this is also a great way to give hackers a leg up to where they don't have to research anything themselves, you simply hand them the answer, and tell them to go out and find yet to be updated sites. So both methods have pro's and con's, and you really only present one side, its better to be open, unless you are the poor site that does get hacked because the world knew your site was vulnerable before you have a chance to respond to the vendors update recommendations.

I can say this for sure being I myself and a few friends have all directly had our Drupal sites hacked while on vacation because security issues were totally made public before I could even have known about the issue. Hence the problem with your "open" model.

Reply

angie

Strange...

The Drupal security announcements don't do full disclosure. They merely mention the severity and type of the exploit. The commit messages are masked as well. So a malicious user still has to make a diff between version X.X and version X.Y, sift through that to find the exact nature of the exploit, and then write code to exploit it. They could just as easily do this with two versions of a product when they read "Enhanced security" in their changelog.

The difference is, Drupal tells you, the website owner, "It's REALLY REALLY IMPORTANT that you update this NOW." EE just casually mentions "There's a new upgrade available," and then claims to be more secure because they don't actually report anything.

Reply

Dai

Misunderstanding

You are assuming that "hackers" are all waiting for a kind gift from the software developers in the form of a security report. In our massively connected world it only takes one hacker to become aware of the exploit then he can post it on hacker forums and that is where all the fanboy hackers will get it from and attack your site, not from the software developers security reports.

So 99.99% of "hackers" don't have to do any work anyway, regardless of the security model, hence the open model is not really making things any easier.

The bad guys are already geared up for the game, the key is to get the good guys geared up as quick as possible, hence why hiding major vulnerabilities from users of the software is not helpful.

Just my 2p

Reply

nate

ExpressionEngine Discussion

A mirroring discussion has begun in the ExpressionEngine forums, considering if EE should switch to a more open security.

I agree with both Angie and Anonymous above. An open security model states more clearly what an issue is than attempting hide the problem does. It's a strength that it encourages users to upgrade, the weakness being that it also points hackers in the same direction. Regardless, an out-of-date site is a danger in either approach.

Reply

chris

Pretty scarey when a company

Pretty scarey when a company will not admit they have issues with their product..
Sound like anyone we all know and love.

Reply

Anonymous

Won't admit they have

Won't admit they have issues? Nate quoted that they admitted it, and discussed conversations with the developers. I may not like how they handled it, but um, let's be fair here - they did admit there were issues and then fixed them promptly.

I know we're all Drupal fans, and nothing I read here will change my mind - so we don't need any FUD. Expression Engine is good software with a good security record.

Reply

Robert Wetzlmayr

Security through obscurity won't work

If there's one thing that history has taught us on security fixes, then it's the fact that given enough malicious eyeballs every vulnerable hole will get exploited.

With all the financial benefits for providers of working exploit code, the incentives are high enough to squash all hopes that any security hole would stay unnoticed. IMHO, Software vendors are absolutely obliged to educate their users to a maximum extent on the risk of postponed updates if these updates fix security related bugs..

Reply

Mike Schinkel

Preaching a distorted a message of salvation

The postings in the Expression Engine forum are great examples of advocates preaching a distorted a message of salvation to the already converted. We see that every day on TV regarding politics. Their desired takeaway of Drupal being less secure than EE is exactly what the majority of the EE crowd wants to hear to validate their own selection of EE so no critical eye will be applied since most EE forum participants use EE. (For that matter, it's also very easy for commenters on Lullabot to post distorted positive views of Drupal to preach to our converted.)

I always have more respect for those who are as even-handed as possible and greatly disrespect those who are not. Although even-handed people are often attacked and demonized by the zealots, I really appreciate their contributions.

That said, good job on your even-handedness Nate.

Reply

lebisol

Dupal maintenance never ends...

Hello Nate,
Thanks for the post as it always nice to see the perspective coming from the 'big boys'.
Surely article is focused on security but Drupal always felt as stated:
...constantly keeping up with vulnerabilities and updates to all of your components can be a full time job....

Which is great to stay sharp with your drupal skills but also very tiring if you are a small web shop or a freelancer?!
It can also read as 'job will never be done'....'hire us and you site will never be finished'.

What if you created 20-30 sites for clients and now have to write letters as many times as the Drupal publishes their security warnings? Would you even send them out or wait?
On other side, what about the plugins security or compatibility?
How do you let the client know that now they can't have features x because 2 developers of plugin x will not keep up with it because they are "busy doing other projects or will not support it for version 6.x"...but hey good news...your core of Drupal is secure. Great, now I have to choose what to give up -between the arm or the leg.

Personally, Drupal sites/projects always felt as if they needed a 'programming team' behind it. Security is just 1 reason,not to diminish the importance of the topic, while there are quite a bit more to consider!
In my mind Drupal was bookmarked as web programmers tool and a framework while Expression Engine more of a web designer tool and a cms. As such, they will never be equal or fair to compare.

@Mike Schinkel
:) you are very political as well...I don't think that posts in thread above mentioned are distorted as some developers have posted quite a bit of Drupal good sides....so, to spin it toward Drupal half of the court...

Just because Drupal's security warnings are more detailed doesn't mean a whole lot...Micro$oft has plenty of them, should this be indicator of 'good product' or a good company?Right?

I have to say it is quite frustrating to receive more notifications on security than 'support' answers from drupal community.

On the other hand so is getting security advisory that consists of nothing more than bullet point. What does 'highly recommended to upgrade' really mean or what does it hide?
-Could it be that Drupal is going through deterioration so it needs duck tape solutions?
-Could it be that EE is hiding the magic?

Great points and...for everyone to decide what works for your project.
Thanks!

Reply

eaton

Some points of confusion :-)

Hi, lebisol!

I'm not Nate, so I can't answer for him, but I can at least offer some thoughts on this issue. As someone who works on the core Drupal software, and maintains a dozen or so plugin modules, and maintains a large number of Drupal sites privately and for clients, I figure I can at least provide some insights into how things work "on this side of the aisle."

What if you created 20-30 sites for clients and now have to write letters as many times as the Drupal publishes their security warnings? Would you even send them out or wait?

I'm not sure how this applies to the discussion -- ExpressionEngine has security holes and fixes them, just like Drupal. This article is a pretty clear account of that very fact! The fact that EllisLabs doesn't explicitly announce the security holes doesn't mean that clients running old EE sites remain secure -- a hacker who peruses the changes between one version of EE and the next can easily spot what changes were made and from that craft an exploit. An outdated version of ExpressionEngine is no more secure than an outdated version of Drupal, or any other software.

On other side, what about the plugins security or compatibility?

Drupal's security announcements cover the 3000+ library of third-party plugins as well as the core software. Your earlier question -- whether I would contact a client when Drupal sends out a security notice -- depends on whether they were using the specific version of the third-party module that contained the security hole. If the hole was in a specific version of the Drupal core software, yes -- I'd recommend they update. Security fixes are published for 'old' versions of Drupal as well, not just the bleeding edge. For a well-built site, that means that 'updating' with a security fix is as simple as FTPing some new files to the server.

How do you let the client know that now they can't have features x because 2 developers of plugin x will not keep up with it because they are "busy doing other projects or will not support it for version 6.x"...but hey good news...your core of Drupal is secure. Great, now I have to choose what to give up -between the arm or the leg.

Again, this is a challenge with any system that supports plugins or extensions -- or any site that allows developers to write custom code to build on the platform's base capabilities. If you choose to use an old, unsupported third-party plugin, that's not a reflection on one security model or the other.

Security is just 1 reason,not to diminish the importance of the topic, while there are quite a bit more to consider!

Absolutely! As Nate said at the beginning of the article, there are many strengths that EE brings to the table, and the Drupal community in particular could learn a lot from it.

Just because Drupal's security warnings are more detailed doesn't mean a whole lot...Micro$oft has plenty of them, should this be indicator of 'good product' or a good company?Right?

No, clearly! :-) No one has argued that 'more detailed' versus 'less detailed' is the critical difference. Obviously, inside the security community, detailed up-to-date announcements are considered vastly superior. The Linux community issues the same style of announcement that Microsoft does, for example. However, that highlights the real issue: when writers compare the number of security announcements for Windows with the number of security announcements for Linux, they are comparing apples and apples.

EllisLabs moderators, in the ExpressionEngine forums, have repeatedly stated -- in no uncertain terms -- that EE is more secure than Drupal. They point to the lack of security announcements for EE, and the list of announcements issued by the Drupal project, as evidence even though they know that the announcements are never issued for EE. Imagine a world where Microsoft issues no announcements when a new security hole is patched, then claims that the lack of announcements is evidence that Windows is more secure than Linux. Clearly, the comparison is silly.

It took one curious developer 24 hours to crack expressionengine.com -- had he been a hacker rather than someone evaluating a product for a client, nothing prevented him from, say, turning demo.expressionengine.com into a trojan horse distributing spyware to anyone visiting the site. Lack of announcements means that you don't know about security holes -- not that they don't exist.

Reply

allgood2

Argument of Approach Not Security

I wish this was an article on the pros and cons of "announcing security vulnerabilities" vs "the quiet release;" because that would be an interesting post. Your title hints at it, and you set the two applications up against it. But then you leave it behind, it even though its not suppose to the post becomes a throw-down between Expression Engine vs Drupal. With Drupal advocates being strong and wordy; and Expression Engine (EE) advocates being a bit absent since this is a Drupal blog.

But also contributing to the absence of advocates is, to some degree decisions have already been made. While some people fall into using EE, most have made a conscious decision: (1) We like the power of the software; (2) we like the flexibility; and (3) we like the security of the software.

Liking the security of the software doesn't mean we think the software is invulnerable. But we enjoy that their has been no mass exploits of the software. EllisLab in the forums, and in release notes are forthcoming about security vulnerabilities.

This doesn't make Expression Engine less secure than Drupal. In all honesty, EE is probably more secure than Drupal, but less secure than a standard comparison of Secunia stats. In fact, this post, is not even really a security comparison between EE and Drupal but rather a debate on which method of reporting do you prefer. I personally like Expression Engine's approach. I'd rather not be on vacation and have my site or any of my client sites hacked, because announcements have been made public, before I have time to act.

I see value in both approaches, and there are occasionally situations where I prefer the open security approach. Typically, I prefer open security approach if I feel too far removed from both the process and the programmers for ongoing development. I'm not a great PHP developer or perl, or python, etc. If I'm looking at your code and can't comprehend it; then I feel more secure if I can contact you or at least get a response from someone on the development team. A responsive development team is sometimes more beneficial than an open security.

So then this becomes an odd conversation on trust —how its extended, valued, and reaffirmed. I like commercial ventures where the source is open, and access to the developers is enviable. It makes me feel secure, if I state I think this is a bug or a security issue; and a patch is provided to me within 24-48hrs, sometimes 2-4hrs, and a release for the entire community a day or so after that; if that long.

Obviously, when access, time, trust, or code comprehension is limited, I tend to lean towards open security. Get it out to the public, make it detailed enough so I know what to do. The difference is like a lover whispering in your ear versus a friend waving you over at a coffee shop. They're both good. Which you prefer at ay giving time though is probably determined by what you need.

Reply

lebisol

Thank you

Thanks eaton & allgood2.
Great to hear from a few big names! - (nothing against us mortals)

I think that most fair statement is:
"An outdated version of ExpressionEngine is no more secure than an outdated version of Drupal, or any other software."

I am curious what Nate has to say and if this was enough of a concern NOT to switch to EE? - since demo.ee.com as of today is 2 revisions outdated.

Thanks to all of you!

Reply

eaton

Some thoughts...

I am curious what Nate has to say and if this was enough of a concern NOT to switch to EE? - since demo.ee.com as of today is 2 revisions outdated.

Again, I'm not Nate, but my opinion is that the security policies alone aren't a reason to avoid EE -- if you keep up on the latest releases and patches for EE and update your sites when fixes are released, the end result is the same as a system like Drupal, Joomla!, etc. In the case of the client that Nate originally evaluated EE for, they decided to stick with Drupal due to a varity of issues (existing infrastructure investments, the ease of maintaining 'multisite' installs on the same codebase, etc.) Security policies were part of it, but far from the only consideration.

I want to jump back in and say again that EE is a REALLY powerful and flexible tool for designers and site builders who want a flexible, template-driven system and don't necessarily need more structured content. When issues of security arise, though, it's importantthat we stick to apples-and-apples comparisons.

Reply

Ashok@Internet

True view for living on Drupal or may be others

I started making websites on Drupal after trying others to some extent. The features and simplicity let me go ahead well on my path.
Initially whenever I find an update and I applied it and relaxed.
But the lineage of secutiry issue compelled me to think over the Drupal Security updates after all "what are it? how they affect? What happens with those who coudn't upade and similar things.

You also can think of numerous issues on your own.

My opinion is simple aproach of giving away too. If I or any one relies on, depends on or live on an open source CMS, I or he must revert back to the CMS in the form of atleast user experience.

What I saw in forums there was quite few attention to the security issues. Till date I was also one of them. Silent spectator or say ignorant one.

I am not a programmer but today I started thinking about how start and came here. This amazing article is my first guide to start with.

Thanks Nate for initiating a revolutionary approach to break the ice of silence.

Reply

Anonymous

uh.... i'm going to wager

uh.... i'm going to wager that Drupal has far more security issues than most modern CMS systems. Same goes for Wordpress, Joomla, etc. The fact remains that these application foundations were built on old technology. We simply didn't have things available to us as programmers with PHP4 that we now have today with PHP5...and the practices, design patterns, and other considerations for enterprise type sites just simply weren't taken into consideration.

I believe ExpressionEngine is using CodeIgniter, no? Or wants to? I don't know, but I know it's newer than Drupal.

It's nice from a developer and stake holder's perspective to know about bugs and security issues. It helps with making the proper decision for a web site...so I am happy that Drupal is very open about their issues. In this regard I agree with everything here.

However...I also very much dislike this:
"a factor to choose Drupal as it presents job security--constantly keeping up with vulnerabilities and updates to all of your components can be a full time job"

That's terrible...and unfortunately it's true. Maintaining a large Drupal site (and I know from experience) is a nightmare. However it's no reason to use Drupal. That's not a defense for Drupal nor an excuse.

People have to switch to solid frameworks and build (and be responsible) for their own code. Stop blaming others. Stop using dated technology.

Good article...but I guess I'm just disappointed in the direction the attitude of this industry is heading.

Reply

Anonymous

I'm no expert here, but you

I'm no expert here, but you say Drupal is using old technology. I dont know if i necesarily agree with that. And neither do the big corporations who are switching to drupal (at a faster and faster rate).

Reply

Nestor Mata

Drupal gets rewrited every time

I definitly disagree that Drupal uses outdated technology, drupal actually gets rewrited every since a while, last year they start Drupal 6 from scratch with the knowlege learned with Drupal 5, at the moment they release Drupal 6, they already had began Drupal 7 and at this point is not released yet, this because there is a huge team rewriting drupal from scratch, new, not old, drupal has several years out there, but, they rewrite it to actually make it new, using a new base, new functions, libraries, and aproaches using also what they have learned with every previous version, the result is a very very mature product, very secure and a huge comunity of really big developers and companies that invest on it, several companies actually invest part of their paid developers to improve and contribute drupal, so Drupal is free, but it has several money invested on it by several companies and independed developers.
Also, the security team sends an email to every one at the moment of any security issue, having the software updated is a must, and even for paid software, are you going to tell me that Windows or Mac OS doesn't have security updates all time, the diference between software like EE and Drupal is the huge team Drupal has on it including paid programmers by companies.
I can also go and find out the security issues in Windows or Mac and create exploits for the people that doesn't update their computers.
Same for any any software you buy.

Sorry to disapoint you, but Drupal is probably one of the most secure software you can find, same as apache (which also has open security policy), if you are aware of how to configure it and use it, like any other software.

Best regards,
Nestor

Reply