Le 21/03/2018, la Security Team de Drupal a annoncé dans son "Public Service
Announcement" PSA-2018-001
la sortie imminente de versions de sécurité pour Drupal, le mercredi 28/03/2018.
De telles préannonces sont particulièrement rares, la précédente remontant à la
faille d'injection SQL "Drupalgeddon" de novembre 2014, et sont réservées aux
mises à jour les plus critiques.
Sévérité / Criticité
En temps normal, la couverture de sécurité est limitée aux versions supportées,
qui sont actuellement la version courante (8.5.x) et la précédente (7.x).
Fait inhabituel là aussi, la mise à jour du 28 couvre également les versions
obsolètes 8.3.x et 8.4.x, et un patch a également été annoncé sur le projet
D6LTS pour une mise à jour équivalente sur Drupal 6.x, alors que son support est
terminé depuis le 24/02/2016, ce qui renforce le niveau de risque estimé de la
faille que corrigent ces mises à jour, et l'importance de les appliquer dans les
meilleurs délais.
Quand agir ?
Mais quels sont ces délais, précisément ? Selon le bulletin PSA-2018-001, les
"exploits" de la faille révélée par le correctif pourraient être développés dans
les "heures ou jours qui suivent" la publication.
En 2014, la faille Drupalgeddon avait commencé à être exploitée dans les 6 heures
qui avaient suivi la publication du correctif. Avec l'élévation progressive du
niveau de risque des agresseurs, tout permet de supposer que le délai pourrait
être encore plus court cette fois.
La Security Team annonce une publication des correctifs mercredi entre 18:00
et 20:30 UTC, soit 20:00-21:30 heure de Paris, du fait de l'heure d'été.
Une marge de sécurité de 6 heures, comme celle dont ont bénéficié les sites en
2014, mène donc au mieux à 03:30 jeudi matin, et au pire 02:00. Dans tous les
cas, une mise à jour le jeudi matin 29/03 court donc un risque important
d'arriver trop tard.
En résumé: préparez votre équipe à une intervention dans la nuit de mercredi
à jeudi.
Stratégie de mise à niveau
Selon le bulletin PSA-2018-001 et les compléments du project D6LTS, la
stratégie recommandée est la suivante:
- Sites sous drupal 8.5.x ou 7.x: appliquer la version de sécurité publiée
dans ce correctif selon la procédure standard.
- Sites sous Drupal 8.4.x: appliquer immédiatement la version 8.4.x qui sera
publiée dans ce correctif, puis planifier une mise à jour vers la plus
récente version 8.5.x de sécurité, annoncée pour le mois d'avril.
- Sites sous Drupal 8.3.x: appliquer immédiatement la version 8.3.x qui sera
publiée dans ce correctif, puis planifier une mise à jour vers la plus
récente version 8.5.x de sécurité, annoncée pour le mois d'avril.
- Sites sous Drupal/Pressflow 6.x avec un contrat de support auprès de l'un
des prestataires du programme commercial D6LTS: suivre les recommandations
spécifiques de ce programme.
- Sites sous Drupal/Pressflow 6.x sans contrat D6LTS: télécharger le patch
disponible sur
https://www.drupal.org/project/issues/d6lts
et l'appliquer au site avec les commandes de patch standard.
Les versions exactes à utiliser pour les mises à jour seront indiquées lors
de la publication du correctif.
Ces mises à jour de sécurité ne modifieront pas le schéma de base de données
par rapport à la dernière version actuellement disponible sur chacune des
branches concernées.
Attention sur les sites utilisant 8.3.x/8.4.x, le rapport du module
update sur le tableau de bord d'administration disponible sur
/admin/reports/status indiquera une mise à jour recommandée vers
une release 8.5.x plutôt que vers la version de sécurité 8.3.x/8.4.x, mais
compte tenu des évolutions entre les versions 8.3/8.4/8.5, ceci présente un
risque d'effets de bord non souhaités, et il est donc préférable d'appliquer les
mises à jour indiquées par le bulletin de sécurité plutôt que celles indiquées
par le site, afin de pouvoir plus sereinement préparer la mise à jour en 8.5.x
pour avril 2018.
Tactique de déploiement
Si votre équipe ou prestataire a d'ores et déjà choisi une tactique, mieux
vaut l'appliquer qu'improviser au dernier moment: ce sont ceux qui sont les
mieux placés pour connaître les contraintes d'exploitation de votre site.
A défaut, quatre principales tactiques sont envisageables pour ce déploiement.
Les détails dépendent évidemment de vos processus de déploiement et, le cas
échéant, de ceux de l'agence ou infogérant en charge de votre site. Cela étant
dit, les grandes lignes tactiques sont les suivantes, et commencent AVANT la
publication du bulletin:
- Avant l'après-midi de mercredi 28, mettre à jour le site à la dernière
version courante sur la branche concernée: 8.3.x, 8.4.x, 8.5.x. Ne pas
tenter à ce stade une mise à jour précipitée vers 8.5.x, pour éviter toute
situation problématique à la veille d'une mise à jour de sécurité critique
- En fin d'après-midi du 28, préparer une sauvegarde intégrale du/des
serveurs, par exemple un snapshot disque. En effet, si un exploit vient à
être réalisé avant la fin du déploiement du correctif, seule une
restauration intégrale de l'infrastructure - par opposition à une
restauration de Drupal seul - permettra de garantir l'absence de maliciel
sur les serveurs. S'assurer que cette sauvegarde est terminée pour 20:00,
heure de publication annoncée au plus tôt
- Dès la publication, télécharger le patch s'il est disponible, ou la version
complète recommandées sinon, et en extraire un patch.
- Appliquer immédiatement le patch en production. Cela permet de fermer la
faille après seulement quelques minutes de vulnérabilité, avec un niveau de
risque fonctionnel des plus limités puisque les sites auront été mis au
dernier niveau de correction de bogues avant mercredi (cf premier point). Si
cette étape n'est pas appliquée, par exemple du fait de règle interdisant les
mises à jour en production dans un processus industrialisé certifié, passer
immédiatement au point suivant, sinon la suite des opérations peut attendre
jeudi matin pour travailler dans de bonnes conditions.
- Intégrer la nouvelle version complète au projet, et lui faire passer la
suite de tests sur l'environnement de recette/préproduction. Une fois la version
validée, la déployer. Fin de l'incident.
- Si le patch a été déployé dès le début, le niveau de risque est très faible,
et le déploiement peut être réalisé sur les serveurs en l'état. Si l'étape
du patch a été omise et que la nouvelle mise en production a été réalisée
moins de 4h après la publication de la version de sécurité, le risque demeure
faible. Mais si, en l'absence de patch, la mise en production a attendu
jusqu'au jeudi matin, il est préférable de réaliser un nouveau cliché des
serveurs, puis de restaurer la version de la veille et de lui appliquer la
nouvelle version avant de revenir en ligne. Le cliché du matin pourra alors
être examiné pour rechercher des traces d'éventuelles tentatives d'intrusion
durant la période de vulnérabilité.
- Si les contraintes organisationnelles ne permettent pas de réaliser les
étapes précédentes, la méthode la plus prudente consiste à mettre le site
hors ligne mercredi juste avant 20:00, avec une page statique signalant le
caractère volontaire/prudentiel de cette interruption de service, et ne le
remettre en ligne qu'une fois la nouvelle version déployée le lendemain
- S'il n'est possible ni de suivre les procédures de mise à jour rapides
précédentes, ni de mettre le site hors ligne jusqu'à la correction, le plus
raisonnable sera de considérer que le site est susceptible d'avoir été
exploité, donc réaliser une sauvegarde intégrale des serveurs et des serveurs
de logs (journaux) disponible, avant de redéployer sur des machines vierges
ou sur la sauvegarde de la veille la version corrigée, puis de procéder à un
audit visant à identifier si une pénétration a effectivement eu lieu. A ce
stade, la présentation
Mon site est hacké, que faire ?
pourra vous être utile
Pour plus d'informations
La Security Team pas plus qu'aucune tierce partie ne peut communiquer plus
d'informations jusqu'à la publication des correctifs.
L'annonce du correctif sera publiées sur https://www.drupal.org/security, sur
Twitter, et par courriel pour les abonnés à la liste de diffusion de la Security
Team, à laquelle il est possible de s'abonner en allant sur sa page de profil
sur https://drupal.org (pas sur https://drupal.fr), et en se rendant sur
l'onglet My newsletters pour s'abonner à cette liste de diffusion.
Les journalistes intéressés par plus d'informations sur les développements
de ce sujet sont invités à contacter directement
security-press@drupal.org
pour obtenir une version centrée sur leurs préoccupations. La Security Team
publiera un courriel résumé à destination de la presse en même temps que la
publication du code et du bulletin de version associé.
Cet article, créé par OSInet est mis
à disposition selon les termes de la
Licence Creative Commons Attribution - Partage dans les Mêmes Conditions 3.0 France.
pour faciliter la diffusion de l'information de sécurité de Drupal.
