-----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 (http://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 http://www.MadIrish.net Any digital signature on this message can be confirmed using the GPG key at http://www.madirish.net/gpgkey -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://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