Drupal

SA-CORE-2013-003 – Drupal core – Multiple vulnerabilities

Leave a comment
  • Advisory ID: DRUPAL-SA-CORE-2013-003
  • Project: Drupal core
  • Version: 6.x, 7.x
  • Date: 2013-November-20
  • Security risk: Highly critical
  • Exploitable from: Remote
  • Vulnerability: Multiple vulnerabilities

Description

Multiple vulnerabilities were fixed in the supported Drupal core versions 6 and 7.

Multiple vulnerabilities due to optimistic cross-site request forgery protection (Form API validation – Drupal 6 and 7)

Drupal’s form API has built-in cross-site request forgery (CSRF) validation, and also allows any module to perform its own validation on the form. In certain common cases, form validation functions may execute unsafe operations. Given that the CSRF protection is an especially important validation, the Drupal core form API has been changed in this release so that it now skips subsequent validation if the CSRF validation fails.

This vulnerability is mitigated by the fact that a form validation callback with potentially unsafe side effects must be active on the site, and none exist in core. However, issues were discovered in several popular contributed modules which allowed remote code execution that made it worthwhile to fix this issue in core. Other similar issues with varying impacts are likely to have existed in other contributed modules and custom modules and therefore will also be fixed by this Drupal core release.

Multiple vulnerabilities due to weakness in pseudorandom number generation using mt_rand() (Form API, OpenID and random password generation – Drupal 6 and 7)

Drupal core directly used the mt_rand() pseudorandom number generator for generating security related strings used in several core modules. It was found that brute force tools could determine the seeds making these strings predictable under certain circumstances.

This vulnerability has no mitigation; all Drupal sites are affected until the security update has been applied.

Code execution prevention (Files directory .htaccess for Apache – Drupal 6 and 7)

Drupal core attempts to add a “defense in depth” protection to prevent script execution by placing a .htaccess file into the files directories that stops execution of PHP scripts on the Apache web server. This protection is only necessary if there is a vulnerability on the site or on a server that allows users to upload malicious files. The configuration in the .htaccess file did not prevent code execution on certain Apache web server configurations. This release includes new configuration to prevent PHP execution on several additional common Apache configurations. If you are upgrading a site and the site is run by Apache you must fix the file manually, as described in the “Solution” section below.

This vulnerability is mitigated by the fact that it only relates to a defense in depth mechanism, and sites would only be vulnerable if they are hosted on a server which contains code that does not use protections similar to those found in Drupal’s file API to manage uploads in a safe manner.

Access bypass (Security token validation – Drupal 6 and 7)

The function drupal_valid_token() can return TRUE for invalid tokens if the caller does not make sure that the token is a string.

This vulnerability is mitigated by the fact that a contributed or custom module must invoke drupal_validate_token() with an argument that can be manipulated to not be a string by an attacker. There is currently no known core or contributed module that would suffer from this vulnerability.

Cross-site scripting (Image module – Drupal 7)

Image field descriptions are not properly sanitized before they are printed to HTML, thereby exposing a cross-site scripting vulnerability.

This vulnerability is mitigated by the fact that an attacker must have a permission to administer field descriptions, for example the “administer taxonomy” permission to edit fields on taxonomy terms.

Cross-site scripting (Color module – Drupal 7)

A cross-site scripting vulnerability was found in the Color module. A malicious attacker could trick an authenticated administrative user into visiting a page containing specific JavaScript that could lead to a reflected cross-site scripting attack via JavaScript execution in CSS.

This vulnerability is mitigated by the fact that it can only take place in older browsers, and in a restricted set of modern browsers, namely Opera through user interaction, and Internet Explorer under certain conditions.

Open redirect (Overlay module – Drupal 7)

The Overlay module displays administrative pages as a layer over the current page (using JavaScript), rather than replacing the page in the browser window. The Overlay module did not sufficiently validate URLs prior to displaying their contents, leading to an open redirect vulnerability.

This vulnerability is mitigated by the fact that it can only be used against site users who have the “Access the administrative overlay” permission.

CVE identifier(s) issued

  • Multiple vulnerabilities due to optimistic cross-site request forgery protection (Form API validation): CVE-2013-6385
  • Multiple vulnerabilities due to weakness in pseudorandom number generation using mt_rand() (Form API, OpenID and random password generation – Drupal 6 and 7): CVE-2013-6386
  • Code execution prevention (Files directory .htaccess for Apache – Drupal 6 and 7): No CVE; considered remediated through “security hardening”
  • Access bypass (Security token validation – Drupal 6 and 7): No CVE; considered remediated through “security hardening.”
  • Cross-site scripting (Image module – Drupal 7): CVE-2013-6387
  • Cross-site scripting (Color module – Drupal 7): CVE-2013-6388
  • Open redirect (Overlay module – Drupal 7): CVE-2013-6389

Versions affected

  • Drupal core 6.x versions prior to 6.29.
  • Drupal core 7.x versions prior to 7.24.

Solution

Install the latest version:

Also see the Drupal core project page.

Warning: Fixing the code execution prevention may require server configuration; please read:

To fix the code execution prevention vulnerability on existing Apache installations also requires changes to your site’s .htaccess files in the files directories. Until you do this, your site’s status report page at admin/reports/status will display error messages about the problem. Please note that if you are using a different web server such as Nginx the .htaccess files have no effect and you need to configure PHP execution protection yourself in the respective server configuration files.

To fix this issue, you must edit or replace the old .htaccess files manually. Copies of the .htaccess files are found in the site’s files directory and temporary files directory, and (for Drupal 7 only) the separate private files directory if your site is configured to use one. To find the location of these directories, consult the error messages at admin/reports/status, or visit the file system configuration page at admin/settings/file-system (Drupal 6) or admin/config/media/file-system (Drupal 7). Note that you should only make changes to the .htaccess files that are found in the directories specified on that page. Do not change the top-level .htaccess file (at the root of your Drupal installation).

Go onto your server, navigate to each directory, and replace or create the .htaccess file in this directory with the contents described below. Alternatively, you can remove the .htaccess file from each directory using SFTP or SSH and then visit the file system configuration page (admin/settings/file-system in Drupal 6 or admin/config/media/file-system in Drupal 7) and click the save button to have Drupal create the file automatically.

The recommended .htaccess file contents are as follows.

For Drupal 6:

# Turn off all options we don't need.
Options None
Options +FollowSymLinks

# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
<Files *>
  # Override the handler again if we're run later in the evaluation list.
  SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
</Files>

# If we know how to do it safely, disable the PHP engine entirely.
<IfModule mod_php5.c>
  php_flag engine off
</IfModule>
# PHP 4, Apache 1.
<IfModule mod_php4.c>
  php_flag engine off
</IfModule>
# PHP 4, Apache 2.
<IfModule sapi_apache2.c>
  php_flag engine off
</IfModule>

For Drupal 7:

# Turn off all options we don't need.
Options None
Options +FollowSymLinks

# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
<Files *>
  # Override the handler again if we're run later in the evaluation list.
  SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
</Files>

# If we know how to do it safely, disable the PHP engine entirely.
<IfModule mod_php5.c>
  php_flag engine off
</IfModule>

Additionally, the .htaccess of the temporary files directory and private files directory (if used) should include this command:

Deny from all

Reported by

Fixed by

Coordinated by

Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at http://drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Drupal version: 
Drupal 6.x
Drupal 7.x

Leave a Reply