Security Public Service Announcements

Subscribe to Security Public Service Announcements feed
Updated: 11 min 24 sec ago

Update on Views Ajax vulnerability for Drupal 7 Views and Drupal 8 core. -- PSA-2017-002

Wed, 08/16/2017 - 10:51pm
  • Advisory ID: DRUPAL-PSA-2017-002
  • Project: Drupal contributed modules
  • Version: 7.x, 8.x
  • Date: 2017-Aug-16
Description

The Drupal Security Team is now aware that the Views ajax access bypass vulnerability (DRUPAL-SA-CONTRIB-2017-068 and SA-CORE-2017-004) released 16 Aug 2017 is more severe than originally announced, because many widely used contrib modules don't have access restrictions set on the default views they provide. Any view that does not have access controls on the default (master) display may be vulnerable. The vulnerability does not require any authentication to be exploited. A successful exploit results in some non-public data being made public.

Sites running versions of Views prior to 7.x-3.17 or Drupal 8 core prior to version 8.3.7 (including Drupal 8.1.x and 8.2.x) should update immediately. Drupal 7 core is only affected if the Views module is enabled.

If you are unable to update Views, you can mitigate this by editing views that contain sensitive data in the Views UI and making sure they utilise one of the permission controls - such as 'require a role' or 'require a permission'. See Views permissions manual page for more information.

Contact and More Information

The Drupal Security Team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

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

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal 8 core upcoming critical release PSA-2017-001

Mon, 04/17/2017 - 11:47am
  • Advisory ID: DRUPAL-PSA-2017-001
  • Project: Drupal core
  • Version: 8.x
  • Date: 2017-Apr-17
Description

There will be a security release of Drupal 8.3.x and 8.2.x on April 19th 2017 between
17:00 - 18:00 UTC
that will fix a critical vulnerability. While we don't normally provide security releases for unsupported minor releases, given the potential severity, the 8.2.x release includes the fix for sites which have not had a chance to update to 8.3.0. The Drupal Security Team urges you to reserve time for core updates at that time because exploits are expected to be developed within hours or days. Security release announcements will appear at the standard announcement locations.

This vulnerability does not affect all Drupal 8 sites; it only affects sites with certain configurations. It requires authenticated user access to exploit. The security release announcement made on April 19th 2017, will make it clear which configurations are affected. If this vulnerability affects your site, you will need to update. Please set aside time on Wednesday to look into this update.

Neither the Security Team, nor Security Team members, nor any Drupal-related company are able to release any more information about this vulnerability until the announcement is made in accordance with our security policies and responsible disclosure best practices.

We provide pre-release warnings when we believe the security risk is high and the steps to exploit are scriptable

Drupal 7 core is not affected by this issue. Contact and More Information

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

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

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity.

PHPmailer 3rd party library -- DRUPAL-SA-PSA-2016-004

Mon, 12/26/2016 - 12:50pm
Description

The PHPMailer and SMTP modules (and maybe others) add support for sending e-mails using the 3rd party PHPMailer library.

In general the Drupal project does not create advisories for 3rd party libraries. Drupal site maintainers should pay attention to the notifications provided by those 3rd party libraries as outlined in PSA-2011-002 - External libraries and plugins. However, given the extreme criticality of this issue and the timing of its release we are issuing a Public Service Announcement to alert potentially affected Drupal site maintainers.

CVE identifier(s) issued
  • CVE-2016-10033
Versions affected

All versions of the external PHPMailer library < 5.2.18.

Drupal core is not affected. If you do not use the contributed PHPMailer third party library, there is nothing you need to do.

Solution

Upgrade to the newest version of the phpmailler library. https://github.com/PHPMailer/PHPMailer

If you are using the SMTP module

The SMTP module has a modified third party PHPMailer library in its codebase. The modified version of the library is not affected.

A special thanks to Fabiano Sant'Ana, SMTP module maintainer, for working on this with short notice.

Reported by
  • Dawid Golunski
Contact and More Information

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

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

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal file upload by anonymous or untrusted users into public file systems -- PSA-2016-003

Mon, 10/10/2016 - 1:09pm
Description

Recently the Drupal Security Team has seen a trend of attacks utilizing a site mis-configuration.
This issue only affects sites that allow file uploads by non-trusted or anonymous visitors, and stores those uploads in a public file system. These files are publically accessible allowing attackers to point search engines and people directly to them on the site. The majority of the reports are based around the webform module, however, other modules are vulnerable to this misconfiguration as well.

For example, if a webform configured to allow anonymous visitors to upload an image into the public file system, that image would then be accessible by anyone on the internet. The site could be used by an attacker to host images and other files that the legitimate site maintainers would not want made publicly available through their site.

To resolve this issue:
  1. Configure upload fields that non-trusted visitors, including anonymous visitors, can upload files with, to utilize use the private file system.
  2. Ensure cron is properly running on the site. Read about setting up cron for for Drupal 7 or or Drupal 8).
  3. Consider forcing users to create accounts before submitting content.
  4. Audit your public file space to make sure that files that are uploaded there are valid.
Awareness acknowledgment

The Drupal Security Team became aware of the existence and exploits of this issue because the community reported this issue to the security team. As always, if your site has been exploited, even if the cause is a mistake in configuration, the security team is interested in hearing about the nature of the issue. We use these reports to look for trends and broader solutions.

Coordinated by

This post may be updated as more information is learned.

Contact and More Information

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

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

Drupal 8.x core release on Monday -- PSA-2016-002

Sun, 07/17/2016 - 12:54pm
  • Advisory ID: DRUPAL-PSA-2016-002
  • Project: Drupal
  • Version: 8.x
  • Date: 2016-July-17
  • Security risk: TBD
  • Vulnerability: TBD
Description

We will be doing a Drupal 8 core patch release on Monday, July 18th. This will occur between 14:15 UTC and 19:00 UTC.

There will not be a Drupal 7 release during this window.

Why is this release being issued?

The Drupal security team has learned that a third-party Drupal 8 dependency will be making a security release on Monday, July 18th and in accordance we will be making a Drupal 8 release soon after. We will not disclose details of the third-party update in advance of that release and cannot respond to requests for further information. This security release is for the dependency only and does not affect Drupal 7 sites. Other mitigating factors will be included with our published SA.

What about the regularly scheduled release window on Wednesday, July 20?

We are moving the regularly scheduled window two days earlier to provide the third-party dependency update, so this replaces that window.

There will not be another core release on Wednesday, July 20th.

Contact and More Information

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

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

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: Drupal 8.x

Drupal contrib - Highly Critical - Remote code execution PSA-2016-001

Tue, 07/12/2016 - 11:18am
Description

There will be multiple releases of Drupal contributed modules on Wednesday July 13th 2016 16:00 UTC that will fix highly critical remote code execution vulnerabilities (risk scores up to 22/25). The Drupal Security Team urges you to reserve time for module updates at that time because exploits are expected to be developed within hours/days. Release announcements will appear at the standard announcement locations.

Drupal core is not affected. Not all sites will be affected. You should review the published advisories on July 13th 2016 to see if any modules you use are affected.

Contact and More Information

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

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

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: Drupal 7.x

Drupal core - Critical - Remote installation PSA-2015-001

Wed, 12/02/2015 - 4:57pm
Description

When a Drupal installation is not completed past the database configuration phase and install.php is left accessible via the internet, any visitor to install.php may complete the installation with a remote database of their selection.

Such a malicious user may use the remote database to execute code on the server.

The above also applies to sites that react to certain hostnames with an installation page and have a sites folder owned or writable by the webserver. Such inadvertent multisites may occur when no default settings.php is present and directory permissions are misconfigured.

These vulnerabilities are mitigated by setting directory and/or file permissions that prevent the webserver from writing to the sites/default/ and sites/ directories.

CVE identifier(s) issued
  • A CVE identifier will be requested, and added upon issuance, in accordance with Drupal Security Team processes.
Versions affected

Drupal 6 core, Drupal 7 core and Drupal 8 core.

Solution

Always complete installations fully on servers exposed to the internet. Ensure that the webserver does not own the sites folder and cannot write to the sites folder.

Consider removing install.php after installation.

Consider installing and automating the execution of Security review which will identify weak file permissions and ownership.

Also see the Drupal core project page.

Coordinated by

Contact and More Information

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

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

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

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

Drupal Core - Highly Critical - Public Service announcement - PSA-2014-003

Wed, 10/29/2014 - 10:39am
Description

This Public Service Announcement is a follow up to SA-CORE-2014-005 - Drupal core - SQL injection. This is not an announcement of a new vulnerability in Drupal.

Automated attacks began compromising Drupal 7 websites that were not patched or updated to Drupal 7.32 within hours of the announcement of SA-CORE-2014-005 - Drupal core - SQL injection. You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement.

Simply updating to Drupal 7.32 will not remove backdoors.

If you have not updated or applied this patch, do so immediately, then continue reading this announcement; updating to version 7.32 or applying the patch fixes the vulnerability but does not fix an already compromised website. If you find that your site is already patched but you didn’t do it, that can be a symptom that the site was compromised - some attacks have applied the patch as a way to guarantee they are the only attacker in control of the site.

Data and damage control

Attackers may have copied all data out of your site and could use it maliciously. There may be no trace of the attack.

Take a look at our help documentation, ”Your Drupal site got hacked, now what”

Recovery

Attackers may have created access points for themselves (sometimes called “backdoors”) in the database, code, files directory and other locations. Attackers could compromise other services on the server or escalate their access.

Removing a compromised website’s backdoors is difficult because it is not possible to be certain all backdoors have been found.

The Drupal security team recommends that you consult with your hosting provider. If they did not patch Drupal for you or otherwise block the SQL injection attacks within hours of the announcement of Oct 15th, 4pm UTC, restore your website to a backup from before 15 October 2014:

  1. Take the website offline by replacing it with a static HTML page
  2. Notify the server’s administrator emphasizing that other sites or applications hosted on the same server might have been compromised via a backdoor installed by the initial attack
  3. Consider obtaining a new server, or otherwise remove all the website’s files and database from the server. (Keep a copy safe for later analysis.)
  4. Restore the website (Drupal files, uploaded files and database) from backups from before 15 October 2014
  5. Update or patch the restored Drupal core code
  6. Put the restored and patched/updated website back online
  7. Manually redo any desired changes made to the website since the date of the restored backup
  8. Audit anything merged from the compromised website, such as custom code, configuration, files or other artifacts, to confirm they are correct and have not been tampered with.

While recovery without restoring from backup may be possible, this is not advised because backdoors can be extremely difficult to find. The recommendation is to restore from backup or rebuild from scratch.

For more information, please see our FAQ on SA-CORE-2014-005.

Written by Coordinated by Contact and More Information

We've prepared a FAQ on this release. Read more at FAQ on SA-CORE-2014-005.

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.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 7.x

DRUPAL-PSA-2014-002 - Drupal core - Information disclosure

Wed, 05/21/2014 - 11:31am
  • Advisory ID: DRUPAL-PSA-2014-002
  • Project: Drupal core
  • Version: 6.x, 7.x
  • Date: 2014-May-21
  • Security risk: Not critical
  • Exploitable from: Remote
  • Vulnerability: Information Disclosure
Description

This is a public service announcement regarding the "access site reports" permission (labeled as "View site reports" in the Drupal 7 administrative interface) provided by Drupal 6 and 7 core.

This permission allows users to see logs (for example, those provided by the core Database Logging module) and other reports via the administrative interface of a Drupal site. Due to the nature of the data logged by various core and contributed modules, users with this permission can see information in the logs that they otherwise may not have access to (for example, the titles of nodes that are restricted by node access).

As such:

  • This permission should be granted to trusted site administrators only. It is now listed as an advanced permission at https://drupal.org/security-advisory-policy, and a future release of Drupal 7 core will mark it as restricted on the permissions page as well.
  • Developers may freely use Drupal's watchdog() function to log relevant information about the actions they are performing (without worrying about minor information disclosure or access bypass issues). However, care should still be taken to only log what is necessary. For example, logging extremely sensitive information such as plain-text user passwords (see SA-CONTRIB-2010-091) would still be considered a security issue because plain-text passwords should never be saved or displayed anywhere on the site.

CVE identifier(s) issued
  • A CVE identifier will be requested, and added upon issuance, in accordance with Drupal Security Team processes.
Versions affected

All versions of Drupal 6 and Drupal 7 core.

Solution

Only grant trusted site administrators the "access site reports"/"View site reports" permission.

Also see the Drupal core project page.

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.


Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: Drupal 6.xDrupal 7.x

DRUPAL-PSA-2014-001 - Media - Access Bypass

Wed, 01/08/2014 - 4:05pm
  • Advisory ID: PSA-2014-001
  • Project: Media (third-party module)
  • Version: 7.x
  • Date: 2014-01-08
  • Security risk: Moderately critical
  • Exploitable from: Remote
  • Vulnerability: Access Bypass
Description

This is a public service announcement regarding the "import media" permission, labeled as "Import media files from the local file system," provided by the Media module.

The Media module provides a method for Drupal administrators to import existing files from an arbitrary location on the server. Users with the 'import media' permission can import any file from the server as local Drupal files, even those outside the Drupal install directory, which could lead to information disclosure.

As such, this permission should be granted to trusted site administrators. In the 7.x-2.x version of the module, you may disable the sub-module named "Media Bulk Upload" to disable this functionality.

CVE identifier(s) issued
  • A CVE identifier will be requested, and added upon issuance, in accordance with Drupal Security Team processes.
Versions affected
  • Media module for Drupal 7.x

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

Solution

Only grant trusted site administrators the "import media" permission.

This permission is not marked as a restricted permission in the following versions:

  • Media module 7.x-1.x versions prior to 7.x-1.4
  • Media module 7.x-2.x versions prior to 7.x-2.0-alpha3+37-dev

Upgrading to the latest release is recommended, but not required.

Also see the Media project page.

Reported by Fixed by
  • Dave Reid the module maintainer and of the Drupal Security Team
Coordinated by
  • Dave Reid the module maintainer and of the Drupal Security Team
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.


Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: Drupal 7.x

PSA-2013-001: Drupal core - Users can insert hidden text and links

Wed, 09/04/2013 - 2:55pm
  • Advisory ID: PSA-2013-001
  • Project: Drupal core
  • Version: 6.x, 7.x
  • Date: 2013-September-04
  • Security risk: Not critical
  • Exploitable from: Remote
  • Vulnerability: Information Disclosure
Description

This is a public service announcement regarding possible insertion of hidden links in comments using core CSS selectors within filtered HTML Text formats ("Input formats" in Drupal 6). Drupal core provides several CSS selectors that, by design, hide elements on the page. Using these selectors it is possible to create links to third-party websites that are hidden within a comment. This technique has been observed on live production websites.

Drupal core provides mechanisms that sanitize user submitted links by adding a rel="nofollow" attribute. This feature can be enabled for Drupal 7 sites at admin/config/content/formats/filtered_html and for Drupal 6 sites at admin/settings/filters/1/configure. Note that these paths are for the default formats provided with core. Your site may define custom formats which should be reviewed and updated as well.

Careful moderation of user submitted comments is always advised. Additionally, automated comment moderation tools may help to mitigate and flag these malicious comment submissions.

Solution

Review user-submitted content on your site to see if untrusted users have posted content that includes classes. Review those classes to see if they will hide unwanted content.

Reported 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.xDrupal 7.x

DRUPAL-PSA-2012-001 - localizations - Cross Site Scripting

Wed, 03/07/2012 - 11:08am
  • Advisory ID: DRUPAL-PSA-2012-001
  • Version: 6.x, 7.x
  • Date: 2012-March-07
  • Security risk: Moderately critical
  • Exploitable from: Remote
  • Vulnerability: Cross Site Scripting
Description

This is a public service announcement regarding possible cross-site scripting risks associated with interface localizations for Drupal. Drupal has cross-site scripting prevention filters in the interface localization import code in Drupal core, however, the extent to which localization can be used to inject markup to webpages is wider, and due to Drupal's localization architecture and code reuse, we cannot tell in advance where the localized text is going to be used and how we should sanitize the translated text. When translated text is used, developers do not expect that it might cause cross-site scripting issues and therefore do not use filtering techniques when the resulting text is assembled into the output.

You should be aware that Drupal's cross-site scripting prevention for interface localizations is not complete and therefore you should review the localizations imported to your site before importing them or ensure that they come from trusted sources. Even Drupal's central localization source, localize.drupal.org has configurable permission system for teams. Those teams where translations are moderated by a team of volunteers are less likely to contain any attack code.

Consequently we are adding translate interface to our list of advanced permissions in our Security advisories process and permissions policy document.

The issue also affect contributed modules like Localization update which automate localization import from localize.drupal.org and compatible servers or String overrides, which allows you to use the localization system to override English built-in text.

Versions affected

Multiple modules can be used to translate the interface text. Some of those are

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

Solution

Given that translations strings can be harmful, you should treat them with the same skepticism that you treat modules. Get them from reputable sources or review them prior to using them.

See also the project page.

Reported by Fixed by

This PSA drafted 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.xDrupal 7.x

PSA-2012-001 - Hash DOS attack prevention with Suhosin needs a .htaccess edit

Wed, 01/11/2012 - 4:37pm
  • Advisory ID: DRUPAL-PSA-2012-001
  • Project: Drupal core
  • Version: 6.x, 7.x
  • Date: 2012-01-11
  • Security risk: Less critical
  • Exploitable from: Remote
  • Vulnerability: Denial of Service
Description

Update, June 12th 2012: this advisory is related to flaws in PHP with CVE identifiers CVE-2011-4885 and CVE-2012-0830. Users are encouraged to update the PHP used for their site to a version that is known to fix those vulnerabilities. See below for mitigation techniques if your site runs a version of PHP that doesn't contain those fixes and you cannot change it.

PHP is vulnerable to a hash collision denial of service (DOS) attack. If an attacker can post a large amount of specifically chosen variables to the site, a large amount of CPU time is consumed preventing service to visitors.

Many users deploy the Suhosin PHP extension to limit the amount of posted variables that will be handled by PHP, thus preventing the DOS attack.

There's an unfortunate interaction with the mbstring extension required by Drupal to work with UTF-8. When the setting mbstring.encoding_translation is updated via .htaccess the mbstring extension changes the PHP POST handlers so that only every other POST variable can be handled by Suhosin.

While Suhosin will still remove half of the variables over the post.max_vars limit, it is ultimately unsuccesful in limiting the amount of posted variables and thus in preventing the hash collision DOS attack.

Versions affected

All versions

Solution

Confirm that the master value of mbstring.encoding_translation is set to Off via:

  • Drupal 7: Reports > Status, then More information on the PHP version (admin/reports/status/php)
  • Drupal 6: Administer > Reports > Status report, then follow the link on the PHP version (admin/reports/status/php)

Next, remove the lines from the file .htaccess in the Drupal root.

For Drupal 7.x remove the lines:

php_flag mbstring.encoding_translation off

For Drupal 6.x remove the lines:

php_value mbstring.encoding_translation 0

If the master value of mbstring.encoding_translation is On, change it to Off via PHP.ini. Contact your hosting provider if necessary.

If you do not use Suhosin, limit the amount of variables posted to your site in another way. You should consider upgrading to PHP 5.3.9 and using its newly introduced directive 'max_input_vars'.

Please note that setting such limits too low (whether via Suhosin or PHP) can break processing on long forms like the permissions administration screen.

It is likely that the near-future will see an update to Suhosin, making the procedure described in this PSA unnecessary.

See also the Drupal core project page.

Reported by
  • Dominic Böttger
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.xDrupal 7.x

PSA-2011-002 - External libraries and plugins

Wed, 06/15/2011 - 3:21pm
  • Advisory ID: PSA-2011-002
  • Date: 2011-June-15
  • Project: External libraries and plugins
Description

Just like there's a need to dilligently follow announcements and update contributed modules downloaded from Drupal.org, there's also a need to follow announcements by vendors of third-party libraries or plugins that are required by such modules.

Drupal's update module has no functionality to alert you to these announcements. The Drupal security team will not release announcements about security issues in external libraries and plugins.

The specific issue precipitating this public service announcement is a cross site scripting vulnerability in (F)CKEditor, a common JavaScript-based WYSIWYG editor used as a library in the modules CKeditor, FCKEditor and WYSIWYG.

Exploit examples are circulating.

Versions affected
  • CKEditor versions prior to version 3.5.4
  • FCKEditor versions prior to version 2.6.4.1
Solution

Follow release announcements by the vendors of the external libraries and plugins you use.

In this specific case, remove the _samples directory from the (f)ckeditor installation or upgrade to a non-vulnerable version. Make sure to test compatibility between Drupal modules and new library versions before deploying.

Reported by

The Drupal security was alerted to this issue by Henry Sudhof.

Contact

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

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.

Pages