Recently, a security researcher reported some vulnerabilities to the Drupal Security Team. The Security Team and researcher worked together to understand the risks and decided that the potential impact was small enough that the reported problems could be fixed in public and that the researcher would write a blog post with their perspective on the situation.

Below are some quotes of the critical issues from the blog post and the Drupal Security Team’s analysis of the risks.

Issue #1: Whenever the Drupal update process fails, Drupal states that everything is up to date instead of giving a warning.

This is not ideal and should be corrected, but the impact is limited to only one page of the Drupal administrative interface. All other pages in the admin interface warn about failures correctly. Also, the Drupal Security Team publishes advisories in many ways (html, email, rss, Twitter, and this update mechanism), precisely because modern security awareness requires that administrators rely on multiple mechanisms.

Help fix the missing warning at https://www.drupal.org/node/2646306

Issue #2: An attacker may force an admin to check for updates due to a CSRF vulnerability on the update functionality

The cross site request forgery (CSRF) vulnerability allows an attacker to achieve two goals: To control the time that an update is triggered, which may provide value if they are able to sniff traffic or poison dns for a brief period. To use a large amount of resources from Drupal.org. As it is, there are millions of sites making multiple requests per day to Drupal.org, so an attacker would have to engage in a rather aggressive campaign to make any noticeable impact because the update service is cached and behind a CDN. The value to an attacker from straining resources on Drupal.org via this indirect method is not a strong motivation.

Help fix this at https://www.drupal.org/node/2646328

Issue #3: Drupal security updates are transferred unencrypted without checking the authenticity, which could lead to code execution and database access.

This is accurate and in the past few days we have been working to switch infrastructure and update processes to use secure channels. Furthermore, we’ve investigated and concluded the following download channels are or were affected.

The core update status module did not use SSL. Fixing is in progress

Downloads via drush, all versions, did not use SSL. This is now fixed for supported versions of Drush.

Download links on project pages did not use SSL by default, but a user could change to use SSL if they chose. This is now fixed.

Our default version control URLs shown to users do not use SSL and SSL is not supported for anonymous copying via revision control, but we are working to to fix this.

File checksums were removed from the release nodes. You can still access them by clicking on view all releases from a project page.

Unencrypted file transfer makes it harder than it should be for users to ensure they obtained the intended files. DNS poisoning or man-in-the-middle attacks between Drupal.org and the person or program performing the download could result in a download of unverified code. Both of these would require a bad actor to be able to have control of the network at some point between your site and Drupal.org’s servers.

We have switched the most common download methods to use https by default and are working to add SSL to anonymous downloads via version control (git). The next step is to release an updated Drupal core.

While we are working to secure all remaining download channels, you can safely obtain code over SSL in the following ways:

Manually download release archives from their project pages.

Use a supported version of drush (7 or higher) to obtain downloads or update information. This will be fully secure after approximately 21:00 UTC on January 8th when rebuilding all the release XML files has been finished

Help fix Drupal core on https://www.drupal.org/node/1538118 and https://www.drupal.org/node/1081192





If you have any questions, please feel free to reach out to security@drupal.org. If you are a member of the press, please use security-press@drupal.org.





