Drupal 6 security update for Views

by Elliot Christenson on February 22, 2017 - 3:12pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

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.

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

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

We're One Year Into Drupal 6 EOL How Long To Go?

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.

My security resolutions for 2017! #SecurityResolutions

by David Snopek on January 31, 2017 - 11:58am

I'm a member of the Drupal Security Team, and many of the services offered by myDropWizard involve assisting our customers to improve the security of their Drupal sites -- so, I know quite a lot about security and try to be mindful about my own computer use.

However, computer security is an on-going process: it can always be improved and so you're never truly done.

In this article, I'm going to share my personal list of security resolutions for 2017!

Maybe you'll find something you'd like to implement as well?

Or perhaps you'd like to share your own security resolutions for this year?

Please share your thoughts in the comments (or on Twitter)!

myDropWizard partnering with Omega8.cc to provide Drupal support for their customers!

by David Snopek on January 19, 2017 - 2:45pm

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!

That means:

  • 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!

myDropWizard is STILL Proud to Partner with Pantheon

by Elliot Christenson on January 17, 2017 - 5:36pm

This isn't a new announcement. In fact, it's not really an announcement at all!

We've supported Pantheon and recommended their hosting since the founding of myDropWizard. But it's something we haven't really gone into in detail on our blog ... until today. :-)

Drupal Site Audit Security Surprises

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.

Drupal 6 workaround for the highly critical vulnerability in PHPMailer

by David Snopek on December 26, 2016 - 5:45pm

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!

Are you a spammer without knowing it? Beware the Print Mail module!

by David Snopek on December 13, 2016 - 1:52pm

One of the really interesting things about providing support and maintenance for lots and lots of sites is that you get to see patterns or certain issues affecting several sites, that you might not notice if you're only responsible for a handful of sites.

Not only does this add to our knowledge base of solutions when a customer has a problem, but it can sometimes allow us to preemptively find a problem before a customer even knows they have it (or point it out when we do a FREE site audit).

Anyway, here's a request we've recently gotten from a couple of customers:

Is our web site compromised?!

Our hosting provider says that we've been sending hundreds of e-mails a day that are setting off alarms with their SPAM filter.

Please help!!!!

It turns out that none of the affected websites were hacked -- it was just a matter of spammers taking advantage of a particular Drupal module: "Print Mail" a sub-module of Print.

It's not a security vulnerability - they're using normal features of the module, just at scale with automation.

If you use this module on any of your sites, or are considering enabling it, please read on for an explanation of the problem and some possible solutions.

Drupal 6: Are You Out of Time?

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!

Elysia Cron on Drupal 6? Audit your permissions!

by David Snopek on November 30, 2016 - 2:07pm

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, a security update for Elysia Cron was released for Drupal 7 per the SA-CONTRIB-2016-062 security advisory.

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.