On October 29, the Drupal Security Team issued a Public Service Announcement (PSA) as a follow-up to Security Advisory SA-CORE-2014-005, which disclosed a serious SQL Injection vulnerability in Drupal 7. Our goals with the PSA were to:
(Speaking of which, if you have not remediated yet, please stop reading and do so.)
While we feel those goals were accomplished, the PSA also resulted in a large volume of press coverage – in fact much more coverage than the original disclosure of the vulnerability on October 15th. Not surprisingly, the general tone of the press coverage was quite negative. Unfortunately, some of the coverage was also inaccurate which we’d like to address here as well as provide additional context regarding our security processes.
While we don’t know the total number of Drupal sites affected, the number is not near 12 million as stated in several publications. Unless disabled, individual Drupal sites report their existence back to Drupal.org and this system reports around 1 million total Drupal sites. While this is not an exact measure of live Drupal sites we can infer that the affected number of specifically vulnerable Drupal 7 sites is more likely to be under 1 million.
SA-CORE-2014-005 was certainly a severe issue, if not the most severe issue in Drupal’s history; but it’s important to recognize all software has bugs and security issues that require a remediation process. Finding, fixing and announcing security patches is evidence of a healthy security process and Drupal is one of the few content management systems with a dedicated security team that covers both Drupal core and contributed code.
The above said, there are lessons from both the original disclosure and the follow-up PSA that might result in some changes to the Drupal Security Team policy and process, however we want to reinforce that we are deeply committed to keeping Drupal secure. We encourage you to read this whitepaper that explains our processes, policies and contains a good overview of Drupal security.
If you ever have questions, please use the public discussion area for general topics at https://groups.drupal.org/security or contact us (firstname.lastname@example.org). Or better yet, get involved. You can find more information on the Drupal Security Team page.
-Drupal Security Team
There are a growing number of licensing-related issues on Drupal.org that are unresolved. Additionally, volunteers who have been tackling licensing issues believe that the policies are often applied inconsistently. The result is that contributors are o…
Drupal 7.34 and Drupal 6.34, maintenance releases which contain fixes for security vulnerabilities, are now available for download. See the Drupal 7.34 and Drupal 6.34 release notes for further information.
Download Drupal 7.34Download Drupal 6.34
On Thursday, November 13th, 2014, Chinese censorship authorities DNS poisoned Drupal.org’s Content Distribution Network, EdgeCast. The Drupal Association and EdgeCast have been working together to fix connection issues to Drupal.org, and believe the is…
Drupal 7.33, a maintenance release with numerous bug fixes (no security fixes) is now available for download. See the Drupal 7.33 release notes for a full listing.
Download Drupal 7.33
Drupal.org is an amazing installation of Drupal. At nearly 13 years old, it is one of the largest, continuously operating examples of Drupal. It is difficult to fathom, but Drupal.org has been upgraded in place from version to version for this entire t…
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”
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:
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.
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.
The biggest issues pointed out by the community had to do with the tone of the language in the documents. Many pointed out that it did not match the values of our community. We took a closer look at organizations such as the Wikimedia Foundation and Mozilla, incorporating some of the approaches they took to make our terms a bit more human. We trimmed and shortened what we could. We clarified where things were ambiguous. The end result is much more in line with our community values.
Some examples of changes include the following:
We did leave some things from the previous draft without major changes, such as bullet points under section C, for example. And we did it for a reason. One of our goals is to make Drupal.org a place where everyone feels comfortable. Additionally, we have to ensure that Drupal.org is protected if a legal issue does arise. Those bullet points are there not because we want to be able to police or censor the activity on the site. This language exists because it protects Drupal.org if one user takes issue with content from another user. We will still use the process outlined in the Drupal Code of Conduct to resolve any issues whenever we can.
With that in mind, please take a look at the latest drafts:
Thank you for all your help in building these documents.
Drupal.org will be affected by maintenance Thursday, October 23rd 14:00 PDT, 21:00 UTC.
Drupal 7.32, a maintenance release which contain fixes for security vulnerabilities, is now available for download. See the Drupal 7.32 release notes for further information.
Download Drupal 7.32
Upgrading your existing Drupal 7 is strongly recommend…
Drupal 8.0.0-beta1 has just been released for testing and feedback! This key milestone is the work of over 2,300 people who have contributed more than 11,500 committed patches to 15 alpha releases, and especially the 234 contributors who fixed 177 “bet…
Drupal.org will be affected by maintenance Tuesday, September 23rd 14:00 PDT, 21:00 UTC.
Joint Security release with WordPress
In big news, we had our first joint release with WordPress. We collaborated together with the WordPress team on a PHP security issue discovered by a security researcher. We’re thrilled that we had an opportunity to work together with others in the open source CMS community. We shared a few tips and tricks and it was great working with the WordPress team.
Keeping Drupal Secure
In keeping with our mission to showcase security best practices at Drupal’s online home, we’ve upgraded https://security.drupal.org to Drupal 7. This ensures we’re on a supported platform. We also took the opportunity to add some new features that help us enhance our team’s efficiency by automating a number of routine tasks.
As part of our dedication to keeping Drupal users safe, we’ve written and announced the Long Term support (LTS) plan for Drupal 6 (https://www.drupal.org/d6-lts-support). This is an important step as we look forward to the release of Drupal 8. Soon we will be introducing two-factor authentication to Drupal.org, thanks to hard work from security team members Ben Jeavons, Greg Knaddison , Neil Drumm, and Michael Hess. (https://groups.drupal.org/node/439868 and https://drupal.org/node/2239973)
And here’s one last, fun note: Security.Drupal.org issues now show up on the drupal.org dashboard if you add the widget. You can get it clicking on dashboard after logging in and adding the widget.
Securing Drupal E-Commerce
Some Drupal security team members were recently involved in putting together a compliance White paper for keeping track of PCI compliance. Anyone who runs a Drupal site and takes credit cards should read the whitepaper. Here’s a little more information:
Version 3.0 of the PCI compliance standard becomes mandatory on January 1st, 2015 and will be a complete game changer for many Drupal eCommerce sites. This includes triple the number of security controls if your website touches credit card information and more. The community supported Drupal PCI Compliance White Paper (http://drupalpcicompliance.org/) will give you a high level overview of what PCI compliance is, why you need to comply, and (most importantly) how to get started. This paper was written and reviewed by several members of the Drupal security team, including Rick Manelius, Greg Knaddison, Ned McClain, Michael Hess, and Peter Wolanin.
We’ve redesigned our Security Advisory system to make evaluating and analyzing security threats easier and more intuitive. This came about after several core contributors informed us that they wanted a better way to address security threats. We sent out a survey through Twitter to learn more about how people write and read the Security Advisories. Based on the responses we put together a new Security Advisory system that takes much of the guesswork out of the process of evaluating threats. We’ve added and reordered elements on the Security Advisory’s criticality scale and added explanations to help people understand where a security problem is on the spectrum of potential threats.
Our Growing Team
We’ve brought a number of new members onto the security team. Please help us give a very warm welcome to our newest security team members:
Alex Pott (alexpott) – IRC nick: alexpott, Organization: Chapter Three
We’re always looking for more qualified people who place a high priority on security. If you’d like to join the security team: https://security.drupal.org/join
This week, we added a feature to projects on Drupal.org to help highlight the contributions made by supporting organizations. Maintainers of distributions, modules, and themes can give credit to organizations that have materially contributed to projects on Drupal.org using the new “Supporting Organizations” field.
How do you use this field? When an organization funds the development of a project or when a company takes on maintainership of a key module in the community, the maintainers of that project can add a reference to one or more of them on the project node. Maintainers may chose to give this credit to any organization that contributes significant code or support to a project.
We noticed that many projects would manually follow this pattern in the project description, but wanted to take it a step further. Not only will this provide a link to the organization, it will also show up on the organization’s marketplace page.
This is just the first step, we are also looking for community feedback and help in providing credit to companies, organizations and customers that contribute to the development of Drupal. Implementing this step will be a key way to show how organizations are giving code and support to Drupal Core. Look for it in the coming months.
Dries has written an excellent post on how we might give credit to organizations and another on the value of hiring a core contributor to help push Drupal forward that were a basis for much of this work.
If you are a project maintainer, take a moment to give some credit to the organizations that have helped build the Drupal ecosystem.
Front page news:
Why do we need a ToS?
Drupal.org has grown organically for many years. Currently the site has thousands of active users that generate lots of content every day. Our current Terms of Service are limited to a short line on the account creation form:
This line is an insufficient ToS for a website of our size. In fact, Drupal.org is probably the only website of this size which operates without a published Terms of Service. This situation is uncomfortable, and even dangerous, for both Drupal community and the Drupal Association, which is legally responsible for Drupal.org and its contents.
We’d like to say thanks to the Drupal.org Content Working Group members and community members who already reviewed proposed documents and provided us with their valuable feedback.
UPDATE: Edits to the original drafts were made on 21st of August, 2014, based on feedback in comments to this post.
UPDATE #2 (03.09.2014): We are postponing ToS/PP official launch and will come back with an updated draft shortly.
Drupal 7.31 and Drupal 6.33, maintenance releases which contain fixes for security vulnerabilities, are now available for download. See the Drupal 7.31 and Drupal 6.33 release notes for further information.
Download Drupal 7.31Download Drupal 6.33
Update: Drupal 7.31 is now available.
Update: Drupal 7.30 and Drupal 6.33 are now available.
Drupal.org will be affected by maintenance Tuesday, July 8th, 11:00 PDT (July 8th, 18:00 UTC).
On February 13, 2008, Drupal 6 was released. The policy of the community is to support only the current and previous stable versions. (When Drupal 6 was released, Drupal 4.7.x was marked unsupported. When Drupal 7 came out, Drupal 5.x was marked un…