Drop Guard response about insecure update process


6 January 2016 was a memorable day for the Drupal community. Probably for the first time since the Drupalgeddon a vulnerability with potential to affect millions of websites was discovered. The report on the insecure Drupal update process, published by IOActive, got immediate traction and responses from Acquia, Drupal Security Team and major players in the community.

The analysis of the risks, however, showed the impact is not significant enough and as a result, the patches to fix the issues listed in the report are still "work in progress" (first and second).

As the updates automation and security is the Drop Guard's only focus and business model, we feel responsible for providing our answer to each of the issues. 

Issue #1 (part 1): Incorrect update statuses

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

This issue affects the display of the core or contrib update status on the "Available updates" screen, in case the update information is not properly fetched from Drupal.org.

First, Drop Guard users don't need to have the Update module enabled at all (one less module enabled, huh!), as they delegate the heavy lifting updates detection work entirely to Drop Guard. 

Second, under the hood Drop Guard uses a combination of the Update Manager code, rewritten to mitigate most common update process issues, our custom update detection logic and manual checks of the modules in question. It happens quite often, when, for example, the security advisory for a module can not be parsed automatically - in this case, our team investigates the issue and adjusts the update status. 

Lastly, long before the report from IOActive was published, Drop Guard was smart enough to stop the updates detection process if the update information couldn't be fetched. In the unlikely case of Drupal.org infrastructure issues or general network problems the worst thing which could happen - the update won't be available to a user unless its status will be properly fetched and confirmed.

Issue #1 (part 2): CSRF vulnerability

The "Check Manually" link can be used to perform a cross-site request forgery (CSRF).

Drop Guard server doesn't use the Update module UI, and don't need it enabled, so there is no risk someone could ever click on the "Check Manually" link at all. 

In case you are using the Update Manager, make sure the update links you see point to the correct drupal.org locations accessible via the secure (https) protocol. Or even better, when the information about the update is available via the UI, go to drupal.org and crosscheck the data on the corresponding project page.

Issue #2: Spying on the network traffic

An attacker may point a website owner to a backdoored version of Drupal by eavesdropping on the unencrypted network traffic between a website and updates.drupal.org domain.

Drop Guard users never visit the "Available Updates" page on their websites, which mitigates this vulnerability. Besides, all the networking with updates.drupal.org services is performed over the encrypted connection on our side.

And luckily, Drop Guard users never download updates via the Update's module interface. We highly recommend not to use this functionality on production sites and verify the data you see in the UI with the one from drupal.org. Same applies for Drop Guard usage - it will never hurt if the updates detected by Drop Guard are compared with the data from Update Manager or the project page before you take any action.

Issue #3: Unencrypted updates transfer

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

As mentioned in the section above, Drop Guard always uses the encrypted connection when fetching updates information from Drupal.org.

The actual update archives from Drupal.org are fetched to our servers via the encrypted connection as well. It's also worth saying that Drupal.org team is working tirelessly to switch infrastructure and update processes to use secure channels, so when trying to access the http://updates.drupal.org/release-history/drupal/7.x for example, you will be redirected to the encrypted version automatically.

So as we can see, the easiest way to ensure that you're not in the risk group (apart from using Drop Guard obviously), is to check if the Update Manager is enabled and used to fetch actual updates to your server, and if yes - it is used wisely with all the precautions mentioned above.

Regardless how you maintain your website, we recommend learning and using proper development workflows and practices and always care about security implications.

Do you still use the Update Manager module to update your Drupal installation? Do you think it's a good practice? What's your experience overall? Please do share your thoughts in comments!