Problem/Motivation
If the video filter man in the middle XSS (eg via evil DNS) is classified as a security issue, shouldn’t the current update status process (eg via admin/reports/updates/update) be marked a security issue as well?
As far as I can see there are no authenticity checks whatsoever on the release data and download.
This can be used to
1 - prevent reception of update alerts via the update status channel
2 - entice admins to install modules from untrusted servers
(this has been cleared by the secteam for public discussion, the suggestion was the Infra queue, but it would need Core support as well).
Steps to reproduce
Enable Update manager
Proposed resolution
- Try to fetch over https.
- Print warning messages on the available updates report and the 'Update' form if the site failed to fetch data, warning admins about proper HTTPS config
- Fallback to the current HTTP URL only if the
'update_fetch_with_http_fallback'
setting has been overridden toTRUE
(defaults FALSE).
E-mailing admins if their site is failing to fetch info is at #3162336: Update manager should email admins when it fails to fetch available update data
Remaining tasks
- Framework manager review
User interface changes
New messages if Update Manager fails to fetch available updates (presumably because the site's PHP isn't configured for outbound HTTPS requests to work):
Available updates report
API changes
N/A
Data model changes
N/A
Release notes snippet
The Update Manager now fetches available update data over HTTPS. Your site's PHP must have OpenSSL properly configured. If that's not possible, you can set $conf['update_fetch_with_http_fallback'] = TRUE;
in your settings.php
file to use the less secure HTTP fallback. See the PHP OpenSSL requirements section of the Drupal.org handbook for more details.