Justin.MadIrish.net

Recently while reviewing a Drupal module for code security I noticed an interesting circumstance that got me thinking. The module itself had several security features built in, and adhered to the Drupal secure coding guidelines. However, the module had installation instructions that directed the user to set it up in such a way that it introduced a huge vulnerability into the overall installation. Thinking about this I wondered if it should be the module developers job to prevent the sort of situation that a user could induce by following the instructions. The installation guides should obviously be amended but even doing this wouldn't prevent a user from recreating the same dangerous situation. Who should be responsible for protecting users from themselves? Should the Drupal core code base prevent such situations from even being possible? It's arguable that they should.

Drupal 6.12 core contains two oft used functions that fail to properly sanitize output. Drupal utilizes the non-standard method of user supplied input sanitizing by scrubbing data as it is retrieved from the data layer, rather than as it is submitted. This leads to many instances of confusion amongst developers and vulnerabilities in Drupal modules. Even the Drupal core is not immune to these sorts of errors. Cross site scripting (XSS) vulnerabilities, or the injection of arbitrary HTML into the data layer that is later rendered without being sanitized, can lead to compromise of Drupal user accounts.

After my latest Drupal module vulnerability disclosure (a cross site scripting (XSS) vulnerability in the Drupal 6 Content Access module) I was contacted by a reporter from a pretty big British news agency who wanted details about the problem. Given the large number of Drupal sites on the web it must have seemed like a vulnerability was a pretty big deal. I quickly responded and let him know that the vulnerability remained relatively obscure and difficult to exploit and probably wasn't worth his time but it got me thinking. Security is a pretty broad field and I spend most of my time on one extreme. Asking me about computer security and privacy is probably a lot like asking a law enforcement agent about home security - you're going to get an answer colored by experience.

After the devolution of discourse between myself and Drupal security I received a very kind phone call from Kieran Lal, of Drupal security, to discuss the situation. I wanted to take the opportunity to post about recent events, that conversation, and my position vis a vis Drupal security. Firstly I'd like to explicitly state that my primary interest in reporting on Drupal security vulnerabilities is getting them addressed and hopefully fixed. I work at an organization that employs Drupal heavily, and I can't responsibly allow modules with known security flaws to be deployed. Similarly I advise a number of people on Drupal in the higher education web space and maintain a list of "approved" Drupal modules that many of my peers use to benchmark their installations.

Drupal (http://drupal.org) is a robust, long lived, and quite vibrant open source content management system (CMS) supported by a broad community. Although Drupal has many of the trappings of an enterprise level CMS such as dedicated development and security teams, commercial backing from companies like Acquia and others, it may not be fully ready for the enterprise. I will define enterprise software as large scale software that supports a diversity of users, separation of privilege and roles, and support for business work flow management.

The Software Engineering Institute, part of Carnegie Mellon University, and the organization that comprises CERT, offers an Advanced Incident Handling (AIH) course that I am currently attending. The course is offered in several locations, I'm taking it in Pittsburgh at SIE. The class is being offered in the SIE building, which is right between CMU and University of Pittsburgh's campuses.

I recently finished the latest installment of the LAMPSecurity.org Capture the Flag exercise. I've managed to get some feedback from folks and the reception is generally good. One review at the Preach Security Blog actually wanted the exercise to be harder :) The LAMPSecurity capture the flag exercises are an outgrowth of some of the training work that I'm doing at my work to train programmers and sysadmins about some common security vulnerabilities. The exercises are designed to simulate real world systems - they have multiple user accounts and each user has different privileges. Users have e-mail and home directories full of files that realistically simulate actual usage.

The Software Engineering Institute, part of Carnegie Mellon University, and the organization that comprises CERT, offers an Advanced Incident Handling (AIH) course that I am currently attending. The course is offered in several locations, I'm taking it in Pittsburgh at SIE. The class is being offered in the SIE building, which is right between CMU and University of Pittsburgh's campuses.