SA-2007-005 (29 January 2007) - Arbitrary code execution on comment preview

  • Advisory ID: DRUPAL-SA-2007-005
  • Project: Drupal core
  • Version: 4.7.x, 5.x
  • Date: 2007-Jan-29
  • Security risk: Highly critical
  • Exploitable from: Remote
  • Vulnerability: Arbitrary code execution

Previews on comments were not passed through normal form validation routines, enabling users with the 'post comments' permission and access to more than one input filter to execute arbitrary code. By default, anonymous and authenticated users have access to only one input format.

The official announcement for Drupal 4.7.5 and 5.0 is here.

Considerations for Drupal 4.6

The official patch essentially adds a call to drupal_validate_form() to comment_form_add_preview() in comment.module. (This function was already called by node_form_add_preview() in node.module.) This checks the form token (to guard against XSS) and validates the form input, among other things making sure that the value returned for each form input presented to the user with multiple options, is in fact one of the available options. By doing so, the user is not able to send arbitrary code in the value for the comment's input format.

The function drupal_validate_form() is part of the new forms API introduced in the 4.7 branch. Prior to this, modules had to validate form input themselves. Fortunately, the versions of comment.module and node.module in the 4.5 and 4.6 branch did validate the filter format input value, in comment_validate_form() and node_validate(), respectively. These functions are always called when previewing or saving comments. So, versions 4.5 and 4.6 are not affected by this exploit.

Incidentally, form tokens were added in 4.6.10, and so aren't available in all versions of the 4.6 branch. The resulting XSS vulnerabilties are present throughout the code, and can only be addressed by upgrading the site in question.

Revision History

27 Feb 2007: Heine Deelstra kindly pointed out that drupal_validate_form() was already called by node_form_add_preview() in node.module. This notice previously stated that the function call was added by this security patch, but in fact the official patch merely adds a comment explaining that the function is called to prevent XSS attacks.

Incidentally, form tokens

Submitted by eric on Thu, 2007-02-01 19:29.

Incidentally, form tokens were added in 4.6.10, and so aren't available in all versions of the 4.6 branch. The resulting XSS vulnerabilties are present throughout the code, and can only be addressed by upgrading the site in question.

I'm a bit confused. are the XSS vulnerabilities in versions earlier or later than 4.6.10 ?

Versions earlier than 4.6.10

Submitted by mvc on Fri, 2007-02-02 00:45.

Versions earlier than 4.6.10 are vulnerable. Form tokens stop attackers from tricking you into clicking on a link and thus using your browser cookies to act as you in the CMS, something all dynamic websites with users with priviledge separation would otherwise be vulnerable to. Drupal fixed this in 4.6.10, so everything before that is open to such social engineering exploits. It meant changing how every single form was handled, though, so it's beyond the scope of this set of backported patches.

This is something that's been known all along, and isn't part of the current security advisory. Basically, I added that note just to explain why I didn't backport that part of the patch.

CSRF vs. XSS

Submitted by dkg on Thu, 2007-03-01 18:28.

Just a minor terminology nitpick: the kind of vulnerabilities form tokens can protect against are CSRF vulnerabilities, which are different from XSS vulnerabilities. Working through the various methods of attack is helpful in thinking about how to adequately protect against them. CSRF is some nasty stuff.