Drupal 7.22 / 6.28 Cross Site Scripting

2013-08-14T00:00:00
ID PACKETSTORM:122814
Type packetstorm
Reporter Justin C. Klein Keane
Modified 2013-08-14T00:00:00

Description

                                        
                                            `-----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  
  
`