Boy Baukema

Boy Baukema 
7 mei 2014

Which Drupal modules can you trust?

Image by Headline Shirts

Software we build depends on an aweful lot of other software, our framework (Drupal), third party modules, libraries (server side and client side!), PHP and it’s extensions, Webserver (Nginx / Apache), OS (Linux), etc.

The question with security audits is always, how far do we go? What third party software should and shouldn’t we audit?

For an application that uses Drupal, it’s pretty clear that we should audit the custom configuration and code as well as verify that all third party library versions used do not contain known vulnerabilities. But should we audit Drupal? Should we audit a popular third party module like Views? How about a less popular one like the Feeds REGEX Parser? What if a Alpha, Beta or Devel version is used?

To help with decision making we built and released the Ibuildings Drupal Security Audit tools.

Using modules-usages-status

To demonstrate usage of the modules-usages-status command we’ll pick a distribution that’s still under development and has a fair number of modules, lightning, and install the drupal_sectools.

1. Install the Drupal installation you want to check

This is out of scope for this blog post. If you are auditting a third party Drupal installation, check with them how to set up an installation.

2. Download and install the drupal_sectools.

Get the latest release from GitHub and install it in sites/all/modules

$ cd sites/all/modules
$ wget https ://\_sectools/archive/v1.0.0.tar.gz
$ tar xzvf v1.0.0.tar.gz
$ rm v1.0.0.tar.gz 
$ ls
drupal\_sectools-1.0.0  README.txt
$ cd ../../../

Check that Drupal can see the module and then enable it:

$ drush pml | grep -i security
 Security    Drupal Security Tool Usage (drupal\_sectools\_usage)    Module  Not installed  7.x-1.0
$ drush en drupal\_sectools\_usage
The following extensions will be enabled: drupal\_sectools\_usage
Do you really want to continue? (y/n): y
drupal\_sectools\_usage was enabled successfully.  

3. Run modules-usage-status (mus) and save the results as a CSV file.

$ drush mus > lightning-mus.csv

4. Do magic with CSV file.

I imported the CSV file to Google Drive and added some simple Conditional Formatting to highlight potential risks (like low usage or dev versions):



Ibuildings Drupal Security Audit: Module Usage Status for Lightning Distribution

Here we can see the following headers:

  • project
    Project the module belongs to (typically you don’t download a module, but rather a project with multiple modules).
  • module
    Module name.
  • enabled
    Is this module enabled or just installed?
    An entire project with no ‘enabled’ modules may be a sign of obsolete code.
  • php
    Version of PHP that this module requires.
    Can be used to determine the minimum version of PHP that the site requires.
  • stability
    Indicated stability. One of the following (in order from least to most stable): Unknown, Dev, Alpha, Beta, RC.
  • version
    Installed version.
    Note that this may have +0-dev or +26-dev attached. This is Drush Make saying that the installed module is x commits (0 or 26 in the given examples) ahead of the specified tag.
    So 2.0-rc3+2-dev means that a version 2 commits ahead of the 2.0 Release Candidate 3 has been installed.
  • usages
    How many reported installs there are for this version of the module.
    Note that we ignore the +COMMITS-dev, so this may be misleading.
  • latest_version
    Latest Stable version of the module.
    This allows you to quickly see if there is a newer stable version.
  • latest_version_usages
    How much the latest stable version is used.
    Allows you to guess the general popularity of the module.
  • project impact
    Not in the CSV export, but you’ll probably want to add this.
    What is the impact of this module / project for the site?
    Is it a minor feature used only by the admins? Or is this going to be on a high traffic homepage?
  • review required
    Not in the CSV export, but you’ll probably want to add this.
    End result, do we want to audit this module?

Making a decision

This is the hard part. Ideally you’d want to audit every single line of code, but usually it is neither cost effective nor even possible given the available budget / time.
And even if you did, it would be no guarantee that you did not miss some odd combination of features and clients that constitutes a vulnerability.

The Ibuildings Drupal Security Audit Tools can help you decide what to focus on by giving you indicators like stability and usage.

Let us know what you think!