Comment atténuer la vulnérabilité SRBDS (CVE-2020-0543) sans redémarrer le serveur

Récemment, des universitaires du groupe de sécurité des systèmes et des réseaux de l’Université Vrije (VUSec) ont publié des détails sur la vulnérabilité CrossTalk ou SRBDS (CVE-2020-0543) dans les processeurs Intel. La vulnérabilité CrossTalk permet à un code contrôlé par un attaquant s’exécutant sur un cœur de CPU de fuir des données sensibles d’autres logiciels s’exécutant sur un cœur différent. Dans cet article, nous allons vous montrer comment atténuer cette vulnérabilité des CPU Intel sans redémarrer le serveur.

Qu’est-ce que CrossTalk ?

La vulnérabilité CrossTalk est un type d’attaque MDS (microarchitectural data sampling), similaire à Spectre, Meltdown ou Zombieload. Elle permet l’exposition et le vol de données sensibles pendant que la machine y accède. Les attaques MDS ciblent les données utilisateur lorsqu’elles sont dans un état transitoire, alors qu’elles résident à l’intérieur du CPU et de nombreux systèmes qui y sont connectés.

La vulnérabilité SRBDS/CrossTalk est une vulnérabilité d’exécution transitoire. Nommée « Special Register Buffer Data Sampling » ou SRBDS (CVE-2020-0543) par Intel, elle permet à un code contrôlé par un attaquant s’exécutant sur un cœur de CPU de fuir des données sensibles d’un logiciel victime s’exécutant sur un cœur différent.

Figure 1 : Conception de l’étape de profilage des instructions de CrossTalk, avec l’aimable autorisation de VUSec

Tout système utilisant un CPU Intel peut être affecté par cette vulnérabilité. Vérifiez ici si votre CPU est affecté.

Atténuation sans redémarrage de la vulnérabilité SRBDS (CVE-2020-0543)

Intel a mis en œuvre son atténuation pour la vulnérabilité SRBDS dans une mise à jour de microcode distribuée aux fournisseurs de logiciels le mardi 9 juin 2020. Cette atténuation nécessite l’installation des derniers correctifs du noyau Linux et de la mise à jour du microcode. Les deux opérations sont traditionnellement effectuées lors d’un redémarrage.

Bien que redémarrer quelques serveurs ne semble pas être un problème, si vous êtes un SysAdmin qui s’occupe de plus de 500 serveurs - cela l’est certainement. Redémarrer toute une flotte de serveurs nécessite généralement une planification minutieuse de la fenêtre de maintenance. Heureusement, la technologie de patching en direct permet d’appliquer des mises à jour de sécurité aux systèmes contre CrossTalk sans redémarrage, tant pour la mise à jour du microcode que pour l’application du correctif du noyau Linux.

Canonical, Red Hat et d’autres fournisseurs de distributions ont publié les correctifs de sécurité pour toutes les distributions Ubuntu prises en charge, Debian, CentOS, Red Hat Enterprise Linux. Et, bien que Canonical et Red Hat aient leur propre solution pour patcher les vulnérabilités sans redémarrage, dans le cas de SRBDS/CrossTalk, vous devez tout de même redémarrer un bureau ou un serveur après la mise à jour.

L’équipe de KernelCare a créé une atténuation sans redémarrage pour CrossTalk/SRBDS afin que vous puissiez éviter de redémarrer les serveurs pour appliquer les correctifs. Trouvez les instructions ci-dessous :

A) Si vous utilisez du matériel, suivez 3 étapes pour protéger vos serveurs contre la vulnérabilité CrossTalk/SRBDS sans redémarrage :

Étape 1 : Inscrivez-vous pour un essai gratuit de KernelCare

KernelCare est gratuit à utiliser pendant 30 jours sur tous vos serveurs, aucune carte de crédit n’est requise pour s’inscrire à un essai. Il est également gratuit pour les organisations de santé pour le reste de 2020 et toujours gratuit pour les organisations à but non lucratif.

Étape 2 : Mettez à jour le microcode sans redémarrage

Exemple : Mise à jour du microcode sur RHEL

Voici l’exemple d’une mise à jour de microcode sans redémarrage sur RHEL. Les instructions pour Debian, Ubuntu, CentOS et d’autres distributions peuvent être trouvées dans la documentation de KernelCare.

Pour les distributions basées sur RHEL, vous pouvez utiliser l’utilitaire microcode_ctl pour mettre à jour le microcode.

Avant de commencer, vérifiez ici si les correctifs pour votre distribution sont prêts. La page est mise à jour toutes les heures.

Obtenez le dernier microcode en mettant à jour le package microcode_ctl

yum update microcode_ctl

Créez un force-late-intel–06–4f–01 dans le répertoire du firmware.

touch /lib/firmware/`uname -r`/force-late-intel-06-4f-01

Exécutez la mise à jour du microcode

/usr/libexec/microcode_ctl/update_ucode

Forcez le noyau à charger le nouveau microcode

echo 1 > /sys/devices/system/cpu/microcode/reload

Vérifiez le nouveau microcode

dmesg | grep microcode  
[ 2.254717] microcode: sig=0x306a9, pf=0x10, revision=0x12  
[ 2.254820] microcode: Microcode Update Driver: v2.01 <[email protected]>, Peter Oruba  
[ 1483.494573] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09  
[ 1483.495985] microcode: updated to revision 0x21, date = 2019-02-13  
[ 1483.496012] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09  
[ 1483.496698] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09  
[ 1483.497391] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09

(Optionnel) Vérifiez à nouveau la nouvelle version du microcode (révisions par cœur)

cat /proc/cpuinfo | grep -e microcode  
microcode : 0x21  
microcode : 0x21  
microcode : 0x21  
microcode : 0x21

Étape 3 : Appliquez les correctifs KernelCare

Vous devez maintenant mettre à jour le noyau Linux pour vous assurer que l’utilisateur local ne peut pas lire les données que vous exécutez sur le CPU. Avec KernelCare, vous pouvez le faire sans redémarrer. Si vous vous êtes inscrit pour l’essai à l’étape 1 - vous êtes prêt et n’avez rien d’autre à faire.

B) Si vous utilisez une VM :

Vous devez uniquement patcher le noyau Linux à l’intérieur de la VM. Assurez-vous que votre nœud hôte est également mis à jour, ce qui est généralement fait par votre fournisseur de services.

Si vous utilisez votre KernelCare - vos correctifs seront livrés automatiquement par KernelCare et vous n’avez pas besoin de faire quoi que ce soit de plus. Si ce n’est pas le cas - inscrivez-vous pour un essai gratuit de 30 jours.