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

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.

Drupal 6 is unaffected by SA-CORE-2016-005

by David Snopek on November 17, 2016 - 12:30pm

Yesterday, SA-CORE-2016-005 was published along with Drupal 7.52 and Drupal 8.2.3 to fix the security vulnerabilities described in that security advisory.

We've received a number of e-mails asking us, "When will the Drupal 6 patch for SA-CORE-2016-005 be released?"

Well, the good news is that Drupal 6 is unaffected by the vulnerabilities described in that security vulnerability, so there will be no patch. We just wanted to officially let everyone know, so there was no longer any confusion or worry. :-)

Thanks!

Higher Ed Drupal: Drupal in Computer Science (Part 2 - Realities)

by Elliot Christenson on November 14, 2016 - 1:13pm

You may have read my previous blog post "Higher Ed Drupal: Drupal In Computer Science". In that post, I detailed  what I hoped to achieve with my students this semester. I'm instructing the Introduction to Computer Science class at the University of Wisconsin-Green Bay.

Drupal 6 security update for Views Send

by David Snopek on November 9, 2016 - 1:08pm

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 Send module to fix a Cross Site Scripting (XSS) vulnerability.

Views Send enables you to send mail to multiple user from a View.

The module doesn't sufficiently filter potential user-supplied data when it's previewing the mail which can lead to a Cross Site Scripting (XSS) vulnerability.

This vulnerability is mitigated by the fact that an attacker must have a role with the permission "mass mailing with views_send".

You can download the patch.

If you have a Drupal 6 site using the Views Send 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).

Don't Leave Your Website Support & Maintenance to Junior Developers

by Elliot Christenson on November 8, 2016 - 11:19am

In talking to Drupal shops and agency about how they do support, we've sometimes heard something like:

We have junior developers / paid interns handle one-off support and maintenance requests as a way to train them!

We provide white-label fixed-monthly-cost support for agencies, so I am a little biased. :-) But I used to run a small Drupal agency and I truly believe that there are a number of potential issues with this view.

From my perspective, certainly: IT IS NOT OK to leave support and maintenance to junior developers.

I'll try to give some detail to explain my viewpoint on this... Read on to learn more!

Clients don’t want to be billed hourly for site maintenance - even if they say they do!

by David Snopek on October 25, 2016 - 11:11am

As Drupal professionals, you and I know that all sites need maintenance and support after they're launched. There's security updates, bugs, minor tweaks and questions to be answered. Clients might not know that, so it's our job to educate them.

We find that it's easiest to discuss this before development starts on their new site, rather than after it's done, but whenever it happens, you'll need to agree to a plan for when things come up.

Most Drupal shops and freelancers default to "hourly as needed". Usually clients will go along with that - or even insist on it!

However, we strongly believe that billing hourly for site maintenance and support is WORSE for clients (and you).

Read more to find why - and learn a better way to do it!

Articles aggregated for consumption on Drupal Planet!

o