Security Public Service Announcements

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

PSA-2011-001 - "Drupal security update" social engineering

Thu, 02/17/2011 - 5:25pm
  • Advisory ID: PSA-2011-001
  • Project: Drupal core and contrib
  • Versions: All versions
  • Date: 2011-February-17
  • Security risk: Not critical
Description

This is a public service announcement regarding a recent social engineering attack via the following mail purporting to come from the Drupal security team.

Hello,

I am a member of the Drupal security team. Our installation records show that your site runs Drupal on PHP [version] and [server]. We have recently found a security problem with that configuration which could allow a hacker to get into the site and delete any posts they want. We have not posted anything about this yet publicly as we want to get this patch out to as many people as possible first.

We have developed a patch for this bug - all you need to do is upload this file to your site in the sites/default/files/ folder (do not change the name of the file) and Drupal will see it and install it for you. We recommend you do this as soon as possible.

Sincerely,
James
Drupal security team

The mail was sent with Drupal Security <drupal_s@yahoo.com> as the (easily-forged) "From" address. It also contained an attachment that was said to be a patch that had to be uploaded and installed. Needless to say that this file contained code to make the system accessible from the outside. If you received a message like the above, do not upload the attached file.

How the Drupal Security Team communicates:

  1. The Security Team does not supply patches to sites.
  2. The Security Team will never ask site administrators to upload random files to their site. We only recommend to update to latest core or contrib releases downloaded from drupal.org.
  3. The Security Team officially uses three forms of communication for Drupal Security Advisories; the update report in your Drupal installation, the posts and RSS feed on http://drupal.org/security, and the newsletter available from your Drupal.org user page. The Drupal Security Team does not publish to a Twitter feed or provide any other official communication channel.
  4. The Security Team will never ask for passwords for your host or your Drupal install.

If you receive communications from someone saying they are a member of the Security Team and their request is questionable, please forward the email to the team at security@drupal.org.

Contact

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

PSA-2010-002 - Views - Administer views permission

Wed, 06/16/2010 - 6:29pm
  • Advisory ID: PSA-2010-002
  • Project: Views (third-party module)
  • Versions: 5.x, 6.x
  • Date: 2010-June-16
  • Security risk: Not critical
Description

This is a public service announcement regarding the "administer views" permission provided by the Views module.

The Views module provides a flexible method for Drupal site designers to control how lists and tables of content are presented. The module grants considerable power to users with "administer views" permission, with much of a site's behaviour being configurable via the views administration pages.

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

Versions affected
  • Views module for Drupal 5.x
  • Views module for Drupal 6.x

Drupal core is not affected. If you do not use the contributed Views module, there is nothing you need to do.

Solution

Only grant trusted site administrators the "administer views" permission.

Contact

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

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