GNU/Linux >> Tutoriels Linux >  >> Linux

Comment atténuer la vulnérabilité 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 (VUSec) de l'Université de Vrije ont publié des détails sur la vulnérabilité CrossTalk ou SRBDS (CVE-2020-0543) dans les processeurs Intel. La vulnérabilité CrossTalk permet au code contrôlé par l'attaquant s'exécutant sur un cœur de processeur de divulguer 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é du processeur 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 à Spectre, Meltdown ou Zombieload. Il 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 dans un état transitoire, car elles résident à l'intérieur du processeur et de nombreux systèmes qui lui sont connectés.

La vulnérabilité SRBDS/CrossTalk est une vulnérabilité d'exécution transitoire. Nommé "Special Register Buffer Data Sampling" ou SRBDS (CVE-2020-0543) par Intel, il 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 de VUSec

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

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

Intel a mis en œuvre son atténuation de la vulnérabilité SRBDS dans une mise à jour du microcode distribuée aux éditeurs 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 au redémarrage.

Bien que le redémarrage de quelques serveurs ne semble pas être un problème, si vous êtes un administrateur système qui s'occupe de plus de 500 serveurs, c'est sûr. Le redémarrage de tout un parc de serveurs nécessite généralement une planification approfondie des fenêtres de maintenance. Heureusement, la technologie de correctifs en direct permet d'appliquer des mises à jour de sécurité aux systèmes contre CrossTalk sans redémarrage, à la fois pour la mise à jour du microcode et l'application du correctif du noyau Linux.

Canonical, Red Hate et d'autres fournisseurs de distribution 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 corriger les vulnérabilités sans redémarrage, dans le cas de SRBDS/CrossTalk, vous devez toujours redémarrer un 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 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 obtenir une licence d'essai gratuite de KernelCare

KernelCare est gratuit 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 gratuit pour toujours pour les organisations à but non lucratif.

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

Exemple :mise à jour du microcode sur RHEL

Ceci est l'exemple d'une mise à jour de microcode sans redémarrage sur RHEL. Les instructions pour Debian, Ubuntu, CentOS et d'autres distributions se trouvent dans la documentation 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.

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

yum update microcode_ctl

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

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

3. Exécutez la mise à jour du microcode

/usr/libexec/microcode_ctl/update_ucode

4. Forcer le noyau à charger le nouveau microcode

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

5. 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

6. (Facultatif) Vérifiez 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 :Appliquer 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 processeur. Avec KernelCare, vous pouvez le faire sans redémarrer. Si vous vous êtes inscrit à l'essai à l'étape 1, vous êtes prêt et vous n'avez rien d'autre à faire.

B) Si vous exécutez sur VM :

Il vous suffit de patcher le noyau Linux à l'intérieur de la machine virtuelle. 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 rien à faire de plus. Si ce n'est pas le cas,  inscrivez-vous pour un essai gratuit de 30 jours .


Linux
  1. Linux - Comment Gnome redémarre-t-il sans privilèges root ?

  2. Comment installer Ubuntu Server sans connexion réseau ?

  3. Comment attendre le redémarrage du serveur avec Ansible ?

  4. Comment puis-je faire en sorte que Centos VM relise sa taille de disque accrue SANS redémarrage

  5. SElinux :Comment passer en mode permissif sans redémarrage ?

Vulnérabilité HTTPOXY :comment protéger et tester votre serveur Web

Comment installer Plex Media Server sur un serveur/bureau Ubuntu 16.04

Comment démarrer Weblogic Admin et Node Manager sans mot de passe

Comment redémarrer le serveur à partir de whm ?

Atlantic.Net Cloud - Comment redémarrer en douceur ou en dur un serveur Atlantic.Net Cloud

Comment restaurer un serveur cloud