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