More details on Drupal SA-CORE-2018-002
Platform.sh customers should visit Safe from DrupalGeddon II aka SA-CORE-2018-02 for the specific steps we took to protect all our Drupal instances.
Earlier today, a critical remote code execution vulnerability in Drupal 6, 7, and 8 was disclosed. This highly-critical issue affects all Drupal 7.x and 8.x sites and most Drupal 6.x sites. You should update immediately any Drupal site you have to versions 8.5.1, 8.4.6, or 7.58, as appropriate.
How to know if I am affected?
We are currently not aware of exploits of this vulnerability in the wild but this will undoubtedly change in the next few hours. Writing an exploit for this is trivial and you should expect automated internet-wide attacks before the day is out.
You should take immediate steps to protect yourself. This is as bad or worse than the previous highly-critical vulnerability SA-CORE-2014-05 that wreaked havoc three and a half years ago affecting more than 12 Million websites.
(Like, seriously, if you are reading this and you are not on Platform.sh or another provider that has put a platform-level mitigation in place, go update your sites and then come back and finish reading. Please. Platform.sh customers, see below for how to quickly update your site.)
Where does the vulnerability come from?
The issue is in Drupal’s handling of HTTP request parameters that contain certain special characters. These characters have special meaning in various places in Drupal, which if misinterpreted could lead to unexpected code paths being executed. The solution in the latest patch is to filter out such values before passing them off to application code.
Fortunately that same strategy can be implemented at the network layer. We have therefore applied the same logic to our Web Application Firewall to reject requests containing such values and deployed it across all projects in all regions, both Platform.sh Professional and Platform.sh Enterprise. That should protect all Drupal and Backdrop installations running anywhere on Platform.sh until they are upgraded.
What to do?
You must update any and all Drupal instances with 6.x, 7.x and 8.x or Backdrop CMS, or verify that your hosting provider has put in place an automated mitigation strategy for this vulnerability. (All Platform.sh clients are safe; our new WAF now detects and blocks all variants of this attack). Even if your hosting provider has a mitigation strategy in place you should update immediately anyway.
Drupal 6.x is no longer maintained and unlike Drupal 7.x and 8.x it does not support automated updates. Third-party support providers may provide a patch but you should make plans to upgrade from Drupal 6 to Drupal 8 as soon as possible.
Hopefully you are using Composer for your Drupal 7.x and 8.x or Drush make for Drupal 7.x, as is the default with Platform.sh installations.
To upgrade Drupal via Composer
To update your Drupal instances, and test nothing breaks you can follow the following simple procedure:
Verify that your composer.json file does not lock down drupal core to a minor version it should be something like “drupal/core”: “~8.0”. Then run:
git checkout -b security_update composer update
Make sure that Drupal Core was updated to 8.5.1 or higher. (Check
git diff). Commit and push your changes:
git commit –am ’fix for SA-CORE-2018-02’ && git push
On Platform.sh you can test that everything is fine on your automatically-generated staging environment, then merge to master putting this to production.
If you do not use Platform.sh you should test this either locally or your testing server; and follow your normal procedure to update your live sites.
To upgrade Drupal using Drush Make
If you are using “Drush Make” style of dependency management, again, make sure you are not locked down to a vulnerable version such as:
projects[drupal][version] = 7.57
if it is, bump it up to
7.58. Then make a branch and update it:
git checkout -b security_update drush pm-update
Commit the changes and push the result to Platform.sh for testing. Once you’re satisfied nothing is broken merge back to master and deploy.
To upgrade Drupal if you're checking Drupal core into your repository
If you’re running a “vanilla” Drupal setup, with all of Drupal checked into Git, the easiest way to upgrade is using
In your local environment, go to your Drupal document root and run:
git checkout -b security_update drush pm-update drupal
Commit the changes and push the result to Platform.sh for testing. Once you’re satisfied nothing is broken merge back to master and deploy. Afterward, look into how to migrate your site to a dependency managed configuration, preferably Composer. It will make maintenance far easier and more robust in the future.
As a reminder, your Platform.sh instances are not vulnerable as they are protected by our WAF. You should still apply the fixes ASAP.