Security Public Service Announcements

Subscribe to Security Public Service Announcements feed
Updated: 2 hours 57 min ago

PSA-2010-001: Policy on release versions and permissions

Thu, 05/13/2010 - 5:24pm
  • Advisory ID: PSA-2010-001
  • Project: Drupal core and contrib
  • Versions: 5.x and 6.x and above
  • Date: 2010-May-13
  • Security risk: None
Description

This is a public service announcement regarding Drupal Security Team policies. In a previous PSA we stated that vulnerabilities in modules which require the "administer content types" permission to be exploited would not receive an official security release with a security advisory (SA) and would be handled publicly much like the way the "administer site configuration" permission was treated. We now maintain a list of permissions that are treated similarly at Security advisories process and permissions policy.

That page also clarifies which projects (modules, themes, and distributions) on drupal.org receive SAs and includes only projects that have an official release that is identified as "Y.x-Z.0" and not for projects in beta, alpha, or even release candidate (RC) stage. This means that a security vulnerability in a 6.x-1.0 or 6.x-2.2 release will receive a SA while a 6.x-1.0-beta10 or 6.x-2.0-RC3 will not receive a SA. A project maintainer may use the "Security update" term to indicate a release that includes security improvements even if there is no SA, but they are not required to do so. Using the "Security update" term will trigger the Update module in Drupal 6.x+ core to alert site maintainers to update their site. The goal with this policy is to ensure that official security releases with SAs are relevant and receive appropriate attention, to allow maintainers to readily fix problems when their project is still in active development, and to permit effective channels of communication between the maintainers and users of a project.

Solution

Only grant the most trusted site administrators the permissions listed on the Security advisories process and permissions policy page.

Be aware that projects on drupal.org will not receive an SA and security vulnerabilities will not be kept private until a project reaches an official release "Y.x-Z.0" status. You are encouraged to use only "Y.x-Z.0" projects for your sites, and to contribute to or sponsor work on projects you use so that they can reach an official release.

Contact

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

Drupal version: Drupal 5.xDrupal 6.xDrupal 7.x

SA-CORE-2009-002 Drupal core - Administer content types permission

Wed, 02/11/2009 - 12:27pm
  • Advisory ID: DRUPAL-SA-CORE-2009-002
  • Project: Drupal core
  • Versions: 5.x and 6.x
  • Date: 2009-February-11
  • Security risk: None
Description

This is a public service announcement regarding the "administer content types" permission. The rise of the Content Construction Kit (CCK) and a legion of powerful CCK field modules have considerably extended the abilities of a user with this permission, with much of a site's behaviour now being configurable via the content types administration pages.

The permission "administer content types" is therefore comparable in scope to the "administer site configuration" permission. Only grant this permission to trusted site administrators.

Solution

Only grant trusted site administrators the "administer content types" permission.

Contact

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

SA-2007-023 - Public service announcement: PHP exploit using Drupal circulating

Wed, 10/17/2007 - 2:29pm
  • Advisory ID: SA-2007-023
  • Project: PHP
  • Version: PHP 4 < 4.4.3, PHP 5 < 5.1.4
  • Date: 2007-October-17
  • Security risk: Critical
  • Exploitable from: Remote
  • Vulnerability: unset() hash / index collision exploit using Drupal (CVE-2006-3017)
Description

The PHP unset() Hash / Index collision vulnerability causes the unset() statement to fail in certain circumstances.

Drupal uses the unset statement to eliminate all non-whitelisted global variables when the option "register_globals" is enabled for your PHP installation. As unset() can be caused to fail on vulnerable versions of PHP, arbitrary global variables can be created. This can easily lead to the execution of arbitrary PHP code with a specially crafted URL, similar to the one shown below, that causes the menu system to call the PHP evaluator with arbitrary code:

http://example.com?_menu[callbacks][1][callback]=drupal_eval&_menu[items...();

An exploit for this is widely circulating. The attack will not work when "register_globals" is set to off.

The issue is not limited to installations with "register_globals" set to on. unset() is used in other parts of the codebase where a bypass may result in unintended actions that may compromise your security.

Versions affected
  • PHP 4 before version 4.4.3.
  • PHP 5 before version 5.1.4.
Solution

Upgrade to the latest version of PHP:

  • When using PHP 4 upgrade to PHP 4.4.7.
  • When using PHP 5 upgrade to PHP 5.2.4.

Always apply the latest security patches to your server components.
You may need to review your server management strategy if you are still running a vulnerable PHP version.

Contact

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

False Drupal XSS alarm on BugTraq

Wed, 01/04/2006 - 11:15am

Someone under the pseudonym "Liz0ziM" sent a false security alarm to BugTraq without first contacting the security team:

http://www.securityfocus.com/archive/1/420671/30/0/threaded

This vulnerability is fixed in Drupal 4.5.6, 4.6.4 and onwards. Drupal's new XSS filter mechanism takes care of all vulnerabilities listed on http://ha.ckers.org/xss.html (and even more).

If you have already updated to at least 4.5.6 / 4.6.4 then you are safe and you do not need to take any action. If you have not updated yet, then we advise you again to do so ASAP.

Pages