Comment atténuer la vulnérabilité de SRBDS (CVE-2020-0543) sans redémarrage du serveur

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

Qu’est-ce que CrossTalk ?

La vulnérabilité CrossTalk est un type d’attaque MDS (échantillonnage de données microarchitecturales), similaire à celle de Spectre, Meltdown ou Zombieload. Elle permet d’exposer et de voler des données sensibles pendant que la machine y accède. Les attaques MDS ciblent les données de l’utilisateur alors qu’elles sont dans un état transitoire, car elles ont résidé à l’intérieur de l’unité centrale et de nombreux systèmes qui lui sont connectés.

La vulnérabilité SRBDS/CrossTalk est une vulnérabilité d’exécution transitoire. Nommée « Échantillonnage de données de tampon de registre spécial » ou SRBDS (CVE-2020-0543) par Intel, elle permet au code contrôlé par l’attaquant de s’exécuter sur un cœur de processeur, ce qui entraîne une fuite de données sensibles du 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 deVUSec

Tout système qui utilise un CPU Intel peut être affecté par cette vulnérabilité. Vérifie ici si ton CPU est affecté.

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

Intel a mis en place son atténuation pour la vulnérabilité SRBDS dans une mise à jour du 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 du redémarrage.

Si le redémarrage de quelques serveurs ne semble pas être un problème, si tu es un SysAdmin qui s’occupe de plus de 500 serveurs, c’en est un. Le redémarrage de toute une flotte de serveurs nécessite généralement une planification minutieuse de la fenêtre de maintenance. Heureusement, la technologie du live patching permet d’appliquer les mises à jour de sécurité des systèmes contre CrossTalk sans redémarrage, tant pour la mise à jour du microcode que pour l’application du patch du noyau Linux.

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

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

A) Si tu utilises du matériel, prends 3 mesures pour protéger tes serveurs de la vulnérabilité CrossTalk/SRBDS sans redémarrage :

Étape 1 :Inscris-toi à une licence d’essai gratuite de KernelCare

KernelCare peut être utilisé gratuitement pendant 30 jours sur tous tes serveurs, aucune carte de crédit n’est requise pour s’inscrire pour un essai. Il est également gratuit pour les organisations de santé pour le reste de l’année 2020 et gratuit pour toujours pour les organisations à but non lucratif.

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

Exemple : Mise à jour du microcode sur RHEL

Voici l’exemple d’une mise à jour du microcode sans redémarrage sur RHEL. Lesinstructions pour Debian, Ubuntu, CentOS et d’autres distributions se trouvent à l’adresse suivante dans la documentation de KernelCare.

Pour les distributions basées sur RHEL, tu peux utiliser la fonction microcode_ctl pour mettre à jour le microcode.

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

1. Obtiens le dernier microcode en mettant à jour le microcode_ctl paquet .

yum update microcode_ctl

2. Crée une force-late-intel-06-4f-01 dans le répertoire firmware.

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

3. Exécute la mise à jour du microcode

/usr/libexec/microcode_ctl/update_ucode

4. Force le noyau à charger le nouveau microcode

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

5. Vérifie 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

6. (Facultatif) Vérifie une nouvelle fois la version du nouveau microcode (révisions par cœur)

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

Étape 3 : Applique les correctifs KernelCare

Tu dois maintenant mettre à jour le noyau Linux pour t’assurer que l’utilisateur local ne peut pas lire les données que tu exécutes sur l’unité centrale. Avec KernelCare, tu peux le faire sans redémarrer. Si tu t’es inscrit à l’essai à l’étape 1 – tu es prêt et tu n’as rien d’autre à faire.

B) Si tu fonctionnes sur une VM :

Tu n’as besoin de patcher que le noyau Linux à l’intérieur de la VM. Assure-toi que ton nœud hôte est également mis à jour, ce qui est généralement fait par ton fournisseur de services.

Si tu utilises ton KernelCare – tes correctifs seront livrés automatiquement par KernelCare et tu n’as rien à faire de plus. Sinon –inscris-toi à un essai gratuit de 30 jours.