Today, there is a Moderately Critical security release for the Views module to fix an Access Bypass vulnerability.
The Views module allows site builders to create listings of various data in the Drupal database.
The Views module fails to call db_rewrite_sql() on queries that list Taxonomy Terms, which could cause private data stored on Taxonomy Terms to be leaked to users without permision to view it.
This is mitigated by the fact that a View must exist that lists Taxonomy Terms which contain private data. If all the data on Taxonomy Terms is public or there are no applicable Views, then your site is unaffected.
If you have a Drupal 6 site using the Views module, we recommend you update immediately! We have already deployed the patch for all of our Drupal 6 Long-Term Support clients. :-)
If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.
Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).
by Elliot Christenson on February 14, 2017 - 6:52pm
Originally, we announced Drupal 6 Long-Term Support (LTS) back in November 2015. We promised support until February 24th, 2017 (one year after official support ended).
Then, we extended support until February 24th, 2018. While we aren't quite ready to commit to extending support beyond that, as we encroach upon that original February 2017 deadline, we wanted to make sure that our clients understand that we will keep handling their Drupal 6 sites for (at least) another year.
At myDropWizard, we've always been huge fans of Omega8.cc and their the Drupal-optimized hosting platform: it's fast, secure, flexible and built specifically for Drupal.
They're also great Open Source citizens! Their control panel is based an Aegir, a Drupal distribution, which they contribute heavily to. And their full hosting platform, BOA, is available on GitHub, so you can run it on your own servers. (We actually use BOA for the Drupal-optimized shared hosting that we offer to our customers.)
They really, really kick ass at Drupal hosting.
However, while they provide excellent support for their hosting, they don't provide any support for their customers' Drupal sites themselves. If you needed to perform a security update, add a new View or Panel, or debug a problem inside of your Drupal site - you were on your own... Until now!
We're happy to announce that we'll be partnering with Omega8.cc to provide support for Drupal sites hosted on their platform!
We're going to make our "Basic" plan (our cheapest plan) available to sites hosted on Omega8.cc. Previously, it was limited to sites hosted on Pantheon
If you contact Omega8.cc support, and your needs are outside the scope of their support, they'll forward you to us to see if we can help! You'll still need to purchase a support plan from us, of course.
We can work directly with Omega8.cc and their support team to get up-to-speed and gain access to your site, so if you need help, we can get started faster
We're really excited to work closer with Omega8.cc, and to help their customers do amazing things with Drupal!
by Elliot Christenson on January 10, 2017 - 6:51pm
I thought it would be a good idea to take a look back at some of our site audits. We undergo a gamut of automated and manual reviews of our clients' site file and databases. Because we have such a diverse array of clients, I surprisingly only saw a few strong trends.
You may have noticed that CVE-2016-10033 came out yesterday, which discloses an Remote Code Execution (RCE) vulnerability in the PHPMailer library which is used by popular contrib modules like SMTP or PHPMailer.
This is a highly critical vulnerability because Remote Code Execution means an attacker can run arbitrary code on your server!
by Elliot Christenson on December 6, 2016 - 6:35pm
Do you still operate a Drupal 6 website? Are you getting questions from your management team, technical teams or even board of directors on pending upgrades? Are they afraid of the Drupal 6 "End of Life"? What should you do? What should you tell them?
Read more to hear some brief thoughts on the big decision!
All the update does is mark the permission to administer Elysia Cron as "dangerous" because it allows users to execute arbitrary PHP code. This is by design, it's an explicity feature of Elysia Cron - if it wasn't intended by the module authors it would have been a Remote Code Execution vulnerability. However, users might not be aware that permission grants the ability to execute PHP, hence the security advisory!
Unfortunately, there isn't a way to mark a permission as dangerous under Drupal 6. There isn't even a way to have seperate machine name and human-readable labels for permissions, so there isn't a straight-forward way to add a user visible message. :-(
So, the Drupal 6 Long-Term Support vendors (us included) have decided to simply announce the problem and ask anyone using the Elysia Cron to audit which users/roles have the "administer elysia_cron" permission and make sure it's OK that they can execute arbitrary PHP code.
We're going to be auditting the permission on our client's sites, so, if you're one of our customers - no need to worry! We'll contact you if we have any concerns.
If you'd like us to handle this and similar issues, as well as have all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.