Drupal Security Team Ignores Multiple XSS Vulnerabilities

The Drupal security team recently released SA-CORE-2009-002 (http://drupal.org/node/372836) which is an advisory that warns that many CCK (http://drupal.org/project/cck) based modules contain Cross Site Scripting (XSS) vulnerabilities that can be exploited by users with 'administer content types' permissions (some examples include the Links module (http://secunia.com/Advisories/33835/), the ImageField module (http://secunia.com/Advisories/33757/) and the Viewfield module(http://www.lampsecurity.org/node/20)) and the . The Drupal security team's rather disappointing advice to rectify this situation was not to fix the vulnerabilities in the module code in question, but rather to limit the scope of users granted 'administer content types' privileges. This response is flawed in several ways.

Imagine the scenario where a large organization has multiple roles in their Drupal deployment. There are roles for "site architects" that handle layout, logic, and organizational tasks for the Drupal site but who do not create content or administer the installation. If one of these accounts was compromised then an attacker could use any of the numerous CCK module related XSS vulnerabilities to inject a script in a common content type and expose every user who tried to create content of that type to an attack. Malicious JavaScript could compromise the machines, and accounts, of the back end users who were creating content on the Drupal site.

Finding a flaw in the security model of an application is serious. Even if exploiting the flaw requires escalated privileges or authentication it is still a flaw. Simply erecting barriers to exploitation doesn't fix the flaw, and is an irresponsible response. Rather than trying to shield the vulnerability, it should be fixed, especially when the fix is relatively straightforward, as is in the case of the CCK modules. The help field for these modules is not properly sanitized before being displayed to the user. One function call could rectify the problem - but rather than insist on module developers securing their code the Drupal security team advises site owners to be wary about permissions models.

A cross site scripting flaw can allow an attacker to subject site users to a number of compromises, from browser based to application based. Given the scope of such a threat there is no compelling reason for leaving the exposed flaw in the codebase. I am perplexed and disappointed by the Drupal security team's response to this issue. It is made even more disappointing by the fact that there are CCK based modules that do properly sanitize output to prevent these attacks. Why the Drupal security team is not insisting that all modules be cleansed of these known flaws is a mystery to me.

The official Drupal security team's response to security vulnerabilities that require specific permissions is:

"If this requires the "Administer content types" permission we do not consider this a security issue. The permission should only be granted to users who are fully trusted."

Thus, the flaw is left intact, for any attacker who manages to compromise an account with the 'administer content types' to exploit. This degrades the overall security of Drupal and makes an attackers job easier by providing known avenues for exploitation.