[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <520B8745.1090604@madirish.net>
Date: Wed, 14 Aug 2013 09:33:57 -0400
From: "Justin C. Klein Keane" <justin@...irish.net>
To: full-disclosure@...ts.grok.org.uk
Subject: Drupal core XSS vulnerability
-----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@...irish.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('@...c' => $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-----
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists