Drupalgeddon2: Should I worry about critical security updates?

No, you should not. You should let us worry about them, and go back to your business.

Seriously, we're getting questions from all kinds of people about whether this matters. I'm a bit surprised that there is any question about that. Would you be concerned if your top salesperson was selling for somebody else? If your cashiers were jotting down credit card numbers when they charged a card? If your office became a well-known spot for illicit drug or gun dealers? If your office had a bunch of scammers squatting and running a pyramid scheme? If your confidential client information could be revealed as easily as using a bic pen on an old Kryptonite lock?

We've seen some variation of every single one of those scenarios. And all of them are possible with a remote code execution flaw in a web application, like yesterday's Drupal security vulnerability.

And yet people still don't take website security seriously.

If you have any question about whether it's important to keep your site up-to-date, review that second paragraph again. And then give us a call. Today.

Back up a second. What's remote blah-di-dy-blah blah code execution?

A "Remote Code Execution" vulnerability is a flaw that allows somebody bad to run whatever code they want inside your website. If this happens to you, it is like having a bad employee with keys to anything in your business. Only you don't even know who the employee is, and they are probably sitting in an entirely different country.

Remote because you don't need to have authorized access to the site or server -- they can get in without a key.

Code is what runs your Drupal or WordPress website, and you can find code snippets to do huge amounts of things without even having to write that code -- code can intercept data going in or out of the website, can attack other sites, can change data, can even plant your favorite celebrity's face on a porn video or generate crypto-cash.

Execution means the bad guy can run the code they put up there remotely, and potentially execute your company. Via lawsuits. From your customers whose data you failed to protect. Or the people you defrauded (or rather, your squatters who now control your website defrauded).

Drupalgedden 2 - Wait, didn't they learn the first time?

Yesterday we patched all of our Drupal maintenance customers for a new security vulnerability, dubbed Drupalgeddon 2, within a few hours of the disclosure.

Not only did we patch all the sites, but we did so automatically, with full backups taken immediately before the patch was applied, across over a dozen different hosting companies, 3 different Drupal versions, scads of different clients. We rocked it -- we had only 3 failures across the entire portfolio, all of which were easily dealt with manually. We can easily handle 4 times the number of sites we currently manage.

We did learn from the first DrupalGeddon, at least how to do it automatically. But then, DevOps is what we do best. Enough bragging. Let's look at the vulnerabilities.

DrupalGeddon the First happened in October 2014. That was a remote code execution vulnerability that at its heart had to do with form parameters posted with malicious keys. When you post data from a form, each field has a key (like username or password) and a value (like "John Doe" and "MyPassword123"). Web developers have long known not to trust any of the values coming from browsers, because those are very easy to fake. Keys? Most web applications look for specific keys and ignore keys they don't recognize.

A huge number of attacks target forms of one sort or another, simply because that's one place where you're meant to put stuff into an application. There's a lot of ways to inject stuff the developer doesn't expect, and if an attacker can figure out some way of getting past the protections used by the web developer, she can trick the application into doing something it's not supposed to do. Like doing things to your data (SQL Injection), adding malicious Javascript (Cross-Site-Scripting, or XSS), getting an admin to submit a form for you (Cross-site request forgery, or CSRF), or a variety of other attacks.

Drupal provides a "Form API" that blocks most of these attacks by design, using a lot of security "best practices".

Drupal has automatic "sanitization" of all form values, if the developer uses the core "Form API" it provides. The Form API is extremely powerful, but adds a fair amount of complexity under the hood -- and complexity means more places a vulnerability can creep in and get overlooked. The Form API uses arrays, nested inside other arrays, nested inside more arrays. Going back to the fundamental web form, this means many keys in the form themselves use an array notation, such as "name[0]" "name[1]". The "name" part of that has gotten correctly sanitized (cleaned to prevent any possible injection) -- but what's inside the brackets is a bit harder (because the PHP language itself helpfully converts these to array keys).

With the first DrupalGeddon, they discovered that an attacker could inject nasty stuff into the brackets, and own the site, along the lines of "name[--"put bad stuff here]".

This time around, the attack is on the Form API itself. The Form API tracks lots of stuff in arrays with keys that start with "#". Of particular concern: "#validate", which designates what function to run when the form is submitted. And happens to share the same function signature as "#submit" -- which gets all the other form values, but assumes the form has already been validated. Let's see. What form might I be able to hijack by bypassing validation? What other function might I be able to run that would load my code instead of what's expected? (This is left as an exercise for the reader...)

This has now happened twice to Drupal. Should I move to WordPress?

Gawd, no. Compared to Drupal, WordPress is a shit-show.

WordPress doesn't even have a Form API. Which means there is no standard way for developers to create forms. Which means if you use code from a developer who isn't extremely competent in how to block CSRF, XSS, SQL Injection, and other far "easier" attacks who rolled their own form, chances are your WordPress site has more security holes than swiss cheese.

WordPress core has a reasonably competent security team watching over it. But the > 54,000 plugins available in the WP repository? You're on your own. The security team might handle working with a plugin author if they get notified about a security issue, but they're not out their poring over plugin code looking for vulnerabilities. And with countless proprietary plugins in widespread use getting little to no external review, it's no wonder we see so many hacked WordPress sites.

There are even some accounts of WordPress sites getting broken into using the same exploit code used in Drupalgeddon the First!

If you have a WordPress site at a regular webhost, and don't know what to do if you went to it one day only to find a blank screen, get ahold of us now so we can make sure you're properly backed up and have a recovery plan! You are at far greater risk than you know...

If you're on a reasonably well-built Drupal site, have this vulnerability patched, have reasonably secure hosting, and strong passwords, you're way better off than most WordPress sites. Drupal has a really strong security record, and the vast majority of security issues reported (and fixed) are "privilege escalation" bugs. The typical security update fixes problems like your janitor who has keys to all of your office can find the combination to your safe written in a folder labeled "Insurance contracts." First off, you need to have a sketchy janitor up to nefarious things (why would you hire somebody like that?). And then they would need to go searching in all the most boring places imaginable.

Is this a Zero-day exploit?

No. And that is exactly why Drupal has such a strong reputation for security.

A "Zero-day exploit" is when there is code that exploits a vulnerability before there is a patch for it -- the code to fix a vulnerability was released after it was getting used in the wild. At worst, this is a One-day exploit -- it's been one day since the fix was released, and we haven't yet seen it exploited in the wild -- but that could change today.

This vulnerability was discovered by a developer doing security research and audits on Drupal code. At this writing, it is still considered "theoretical" but that is not going to last long.

Disclosing possible issues, and patching them before they are exploited in the wild, is a hallmark of a project that takes security seriously.

Compared to WordPress, the Drupal security team covers not just Drupal core, but also thousands of contributed modules hosted on Drupal.org -- look for the security badge for any module you use and make sure it has security team coverage if you're concerned.