-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

NB:  Before anyone gets their panties in a twist read the whole
disclosure, this isn't the end of the world, sky-is-falling
vulnerability you might be looking for, but I do believe it is
serious.  TLDR: check your .info files!

Vulnerability Report

Author: Justin C. Klein Keane <justin@madirish.net>
Reported: 7 August, 2013

Description of Vulnerability:
- -----------------------------
Drupal (https://drupal.org) is a robust content management system (CMS)
written in PHP and MySQL.  Drupal core suffers from multiple
persistent (stored) cross site scripting (XSS, or arbitrary script
injection) vulnerabilities because the core System module, included in
all Drupal sites, fails to sanitize module names and descriptions
provided in module metadata files (identified by their .info
extension) before display in some locations.

Systems affected:
- -----------------
Drupal 7.22 and 6.28 were tested and shown vulnerable.  Other versions
are likely affected.

Impact
- ------
Attackers can inject arbitrary HTML (including JavaScript) in order to
attack site administrators.  This could lead to account compromise
(which could in turn lead to arbitrary PHP code execution privileges),
or expose administrative users to client side malware attacks.

Mitigating factors:
- -------------------
In order to inject arbitrary script malicious attackers must have the
ability to manipulate module .info files on a site filesystem, perhaps
via permissions misconfiguration, or to manipulate these files in
modules before they are deployed to a site, such as with the Features
module (https://drupal.org/project/features).  It would be quite rare
to be able to manipulate a .info file without the ability to
manipulate actual PHP code contained in modules.  However, malicious
script contained in .info files would likely be overlooked in any
security audit since these files are assumed to be inert text files,
devoid of any scripting, markup, or executable code.  It is worth
noting that the content of .info files is sanitized for display in
some locations, but this treatment is not uniform.  Thus the
likelihood of an attack via this vector is LOW, but the impact is
extremely high, and the attack would likely escape notice by most
automated and manual security countermeasures.

Proof of Concept Exploits:
- -----------------
1.  Install Drupal 7-22
2.  Create a new directory in the /sites/all/modules named "evil"
3.  Create the file evil.info in the /sites/all/modules/evil directory
to include the following content:
name = <script>alert('evil name');</script>
description = <script>alert('evil desc');</script>
core = 7.x
package = Other
version = 7.x-1.0
project = evil_feature
dependencies[] = system

4.  Create the file evil.module in the /sites/all/modules/evil
directory to include the following contents:
<?php
/**
 * @file
 * Drupal needs this blank file.
 */

5.  Navigate to the Modules administration screen at ?q=admin/modules
to view the rendered JavaScript alerts
6.  Note that the listing of the evil module name under the System
module is properly sanitized

Patch:
- -------------
The following patch mitigates this vulnerability in Drupal 7:

- --- modules/system/system.admin.inc  2013-04-03 17:29:52.000000000 -0400
+++ modules/system/system.admin.inc  2013-08-07 10:47:29.277279676 -0400
@@ -979,10 +979,10 @@ function _system_modules_build_row($info
   );
   // Set the basic properties.
   $form['name'] = array(
- -    '#markup' => $info['name'],
+    '#markup' => check_plain($info['name']),
   );
   $form['description'] = array(
- -    '#markup' => t($info['description']),
+    '#markup' => t("@desc", array('@desc' => $info['description'])),
   );
   $form['version'] = array(
     '#markup' => $info['version'],


Vendor Response:
- ----------------
The Drupal Security Team considers this vulnerability worthy of public
discussion.  The team points out that an attacker able to manipulate a
.info file would likely be able to manipulate PHP code found in other
files in the same directory.  Furthermore, the Drupal Security Team
feels this issue is already public (https://drupal.org/node/637538),
however the public discussion only concerns the development of the
next major release of Drupal - Drupal 8.  There is no mention in the
public discussion, of the fact that this issue faces both current
supported release versions (Drupal 7 and Drupal 6) and likely previous
releases.

- -- 
Justin C. Klein Keane
https://www.MadIrish.net

Any digital signature on this message can be confirmed using
the GPG key at https://www.madirish.net/gpgkey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iPwEAQECAAYFAlILhzQACgkQkSlsbLsN1gDJjgb+MFQ5xee1G5zfZ25T2jpMLztb
Y/UFjB068iAytm6ogTg35Iyz9y/aBNapPvVLCMRy8rmYtywJIpORy6Jxnwsyxxq+
Lkf3SeXXGHG1V7gDSVtt+H+SDtpRS3aqYigYVb+Ia6tlkfb2IR7dBdUWCVuT3789
Qf2NPbVqdxvn2xHVGItnto1qKfqd4AqssATtBoe/hdE/ti7QOgQmxg7yA9fi4KBU
uhdd6Skq8ZLsbacFSA45jpT9QRJPnQt6tWWiF7ePU/e/xZjrIUZZWHDHTHo8ntpk
fQVjZlI7cOwojrP9sd0=
=rilD
-----END PGP SIGNATURE-----

----------------------------------------------------------------
Date: Wed, 14 Aug 2013 08:00:39 -0600
From: Greg Knaddison <greg.knaddison@gmail.com>
To: "Justin C. Klein Keane" <justin@madirish.net>
Cc: full-disclosure@lists.grok.org.uk

Thanks to Justin for identifying and describing this issue.

With a little more detail inline.

On Wed, Aug 14, 2013 at 7:33 AM, Justin C. Klein Keane
<justin@madirish.net> wrote:
<snip>
> Mitigating factors:
> - -------------------
> In order to inject arbitrary script malicious attackers must have the
> ability to manipulate module .info files on a site filesystem, perhaps
> via permissions misconfiguration,

It feels unclear to me if the permissions mentioned here are Drupal
permissions or others. So, to be clear, this would require server file
permission misconfiguration. The info files are placed in the same
directories as php code. For this vulnerability to be significant it
would require permissions like:

-rw-rw-rw-  1 deployuser  deployuser    243 Jan  7  2013 machine_name.info
-rw-rw-r--  1 deployuser  deployuser    434 Jan  7  2013 machine_name.install
-rw-rw-r--  1 deployuser  deployuser   3802 Jan  7  2013 machine_name.module

Or maybe:

-rw-rw-r--  1 deployuser  somegroup    243 Jan  7  2013 machine_name.info
-rw-r--r--  1 deployuser  somegroup    434 Jan  7  2013 machine_name.install
-rw-r--r--  1 deployuser  somegroup   3802 Jan  7  2013 machine_name.module

In the first scenario the attacker would just need a shell on the
server. In the second scenario the attacker would need a shell on the
server and membership in somegroup.

<snip>

> feels this issue is already public (https://drupal.org/node/637538),
> however the public discussion only concerns the development of the
> next major release of Drupal - Drupal 8.  There is no mention in the
> public discussion, of the fact that this issue faces both current
> supported release versions (Drupal 7 and Drupal 6) and likely previous
> releases.

I updated that issue to include Drupal 7 and Drupal 6 mentions.

It's true this affects previous releases, but previous releases are
explicitly EOL and full of holes that are not documented.
* Drupal 5 EOL Announcement: https://drupal.org/node/1027214
* Drupal 4.7 EOL Announcement: https://drupal.org/node/225729

Regards,
Greg