Plus tôt cette semaine, une équipe de chercheurs du Project Zero de Google a découvert à propos de Meltdown et Spectre vulnérabilités qui affectaient de nombreux processeurs modernes, y compris certains processeurs d'Intel, AMD et ARM. Même si AMD a affirmé qu'il n'y avait aucune chance que leurs processeurs soient affectés par ces failles, les chercheurs ont indiqué que la vulnérabilité Meltdown est exclusive aux processeurs Intel, tandis que la vulnérabilité Spectre peut éventuellement affecter certains processeurs Intel, AMD et ARM.
Selon Câblé , "les fabricants d'Intel, d'AMD et d'ARM travaillent en étroite collaboration avec des sociétés de matériel qui expédient leurs processeurs et des sociétés de logiciels comme Apple, Google, Microsoft, la fondation Linux pour publier des correctifs pour ces failles de sécurité. Nous ne pouvons pas garantir les correctifs résoudront complètement ces problèmes. Mais, au moins, mieux qu'il n'y paraissait au départ".
Que pouvez-vous faire maintenant ?
Greg Kroah-Hartman a déjà annoncé la sortie des noyaux stables 4.14.12, 4.9.75 et 4.4.110 qui sont livrés avec les correctifs Meltdown et Spectre. Ainsi, si vous utilisez un processeur Intel, AMD ou ARM, il est fortement recommandé de vérifier si votre système Linux est affecté par les vulnérabilités Meltdown And Spectre et de le corriger immédiatement en mettant à jour le dernier noyau Linux. Si votre distribution Linux ne dispose pas encore des dernières mises à jour du noyau Linux, il est fortement recommandé de modifier votre distribution Linux dès maintenant.
Vérifiez les vulnérabilités Meltdown et Spectre
Sur Arch Linux et ses dérivés, vous pouvez savoir si votre système est affecté par des vulnérabilités de fusion/spectre à l'aide des deux commandes suivantes.
$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz
$ dmesg | grep iso Si les commandes ci-dessus ne renvoient RIEN, votre système n'est pas encore corrigé. Donc, vous devez mettre à jour votre système basé sur Arch en utilisant la commande :
$ sudo pacman -Syu
Après avoir entièrement mis à jour votre système Arch, redémarrez et exécutez à nouveau les commandes ci-dessus. Si votre système est corrigé, vous devriez voir la sortie suivante pour la première commande :
CONFIG_PAGE_TABLE_ISOLATION=y
Et vous obtiendrez cette sortie pour la deuxième commande.
[ 0.000000] Kernel/User page tables isolation: enabled
J'ai déjà mis à jour le noyau dans mon système Arch. Comme vous le voyez dans la sortie ci-dessus, mon noyau Linux est 4.14.12-1-ARCH et il est déjà corrigé. Si vous n'avez pas encore mis à jour votre système Arch, vous n'obtiendrez aucune sortie.
Les commandes ci-dessus peuvent ne pas fonctionner dans Ubuntu. Heureusement, quelques bons samaritains sur Askubuntu forum a publié une solution de contournement pour savoir si vos systèmes Ubuntu sont corrigés ou non à l'aide de l'une des commandes suivantes.
$ grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && echo "patched :)" || echo "unpatched :(" $ grep cpu_insecure /proc/cpuinfo && echo "patched :)" || echo "unpatched :(" $ dmesg | grep "Kernel/User page tables isolation: enabled" && echo "patched :)" || echo "unpatched :(" Si la sortie est non corrigée , votre système n'est pas encore corrigé. Mettez à jour le noyau immédiatement pour appliquer les correctifs.
J'utilise toujours 4.4.0-104-generic dans mon système Ubuntu, donc je reçois "non corrigé" dans le résultat de toutes les commandes.
Mettez à jour votre noyau immédiatement en utilisant la commande :
$ sudo apt-get update
$ sudo apt-get dist-upgrade
Ou, comme décrit dans le lien suivant.
- Utilitaires du noyau Linux – Scripts pour compiler et mettre à jour le dernier noyau Linux pour Debian et ses dérivés
Après avoir mis à jour votre noyau, exécutez à nouveau ces trois commandes et vous verrez que votre système Ubuntu est corrigé !
Pour les autres distributions Linux, il existe un script nommé "Spectre &Meltdown Checker" pour vérifier les vulnérabilités Meltdown/Spectre. Ce script vous aidera à déterminer si votre installation Linux est vulnérable aux 3 CVE "à exécution spéculative".
Git clone ce script :
$ git clone https://github.com/speed47/spectre-meltdown-checker.git
Cela clonera tout le contenu dans un répertoire nommé "spectre-meltdown-checker" dans votre répertoire de travail actuel.
Accédez à ce répertoire :
$ cd spectre-meltdown-checker/
Rendre le script exécutable :
$ chmod +x spectre-meltdown-checker.sh
Enfin, lancez-le pour trouver les vulnérabilités :
$ sudo ./spectre-meltdown-checker.sh
Voici l'exemple de sortie de mon système Ubuntu patché :
Sans options, il inspectera votre noyau en cours d'exécution. Vous pouvez également spécifier une image du noyau sur la ligne de commande, si vous souhaitez inspecter un noyau que vous n'exécutez pas.
Mise à jour :
Le script spectre-meltdown-checker est disponible dans les dépôts officiels de certaines distributions Linux.
Sur Debian, Ubuntu :
$ sudo apt install spectre-meltdown-checker
Sur CentOS, RHEL :
$ sudo yum install epel-release
$ sudo yum install spectre-meltdown-checker
Sur Fedora :
$ sudo dnf install $ sudo apt install spectre-meltdown-checker
Après avoir installé spectre-meltdown-checker, exécutez-le en tant qu'utilisateur root ou avec les privilèges sudo pour vérifier les vulnérabilités Spectre et Meltdown :
$ sudo spectre-meltdown-checker
Exemple de résultat :
Spectre and Meltdown mitigation detection tool v0.37
Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-91-generic #92-Ubuntu SMP Fri Feb 28 11:09:48 UTC 2020 x86_64
CPU is Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU microcode is known to cause stability problems: NO (model 42 stepping 7 ucode cpuid 0x206a7)
* CPU vulnerability to the three speculative execution attack variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: NO (Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers)
* Kernel has array_index_mask_nospec (x86): UNKNOWN (couldn't check (missing 'readelf' tool, please install it, usually it's in the 'binutils' package))
* Kernel has the Red Hat/Ubuntu patch: UNKNOWN (missing 'strings' tool, please install it, usually it's in the binutils package)
* Kernel has mask_nospec64 (arm): UNKNOWN (couldn't check (missing 'readelf' tool, please install it, usually it's in the 'binutils' package))
* Checking count of LFENCE instructions following a jump in kernel... UNKNOWN (couldn't check (missing 'readelf' tool, please install it, usually it's in the 'binutils' package))
> STATUS: VULNERABLE (Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: NO (Vulnerable, STIBP: disabled)
* Mitigation 1
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: UNKNOWN
* Kernel is compiled with IBPB support: UNKNOWN (in offline mode, we need the kernel image to be able to tell)
* IBPB enabled and active: NO
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
> STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB is needed to mitigate the vulnerability)
> How to fix: To mitigate this vulnerability, you need either IBRS + IBPB, both requiring hardware support from your CPU microcode in addition to kernel support, or a kernel compiled with retpoline and IBPB, with retpoline requiring a retpoline-aware compiler (re-run this script with -v to know if your version of gcc is retpoline-aware) and IBPB requiring hardware support from your CPU microcode. The retpoline + IBPB approach is generally preferred as the performance impact is lower. More information about how to enable the missing bits for those two possible mitigations on your system follow. You only need to take one of the two approaches.
> How to fix: The microcode of your CPU needs to be upgraded to be able to use IBPB. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section). An updated CPU microcode will have IBRS/IBPB capabilities indicated in the Hardware Check section above. If you're running under an hypervisor (KVM, Xen, VirtualBox, VMware, ...), the hypervisor needs to be up to date to be able to export the new host CPU flags to the guest. You can run this script on the host to check if the host CPU is IBRS/IBPB. If it is, and it doesn't show up in the guest, upgrade the hypervisor.
> How to fix: Your kernel doesn't have IBPB support, so you need to either upgrade your kernel (if you're using a distro) or recompiling a more recent kernel.
> How to fix: The microcode of your CPU needs to be upgraded to be able to use IBRS. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section). An updated CPU microcode will have IBRS/IBPB capabilities indicated in the Hardware Check section above. If you're running under an hypervisor (KVM, Xen, VirtualBox, VMware, ...), the hypervisor needs to be up to date to be able to export the new host CPU flags to the guest. You can run this script on the host to check if the host CPU is IBRS/IBPB. If it is, and it doesn't show up in the guest, upgrade the hypervisor.
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: NO (Vulnerable)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: NO
* Reduced performance impact of PTI: NO (PCID/INVPCID not supported, performance impact of PTI will be significant)
* Running as a Xen PV DomU: NO
> STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability)
> How to fix: If you're using a distro kernel, upgrade your distro to get the latest kernel available. Otherwise, recompile the kernel with the CONFIG_PAGE_TABLE_ISOLATION option (named CONFIG_KAISER for some kernels), or the CONFIG_UNMAP_KERNEL_AT_EL0 option (for ARM64)
A false sense of security is worse than no security at all, see --disclaimer Comme vous pouvez le voir dans la sortie ci-dessus, les problèmes Spectre et Meltdown ne sont pas encore corrigés.
Patch Meltdown et Spectre Vulnérabilités
Comme je l'ai déjà mentionné, il est fortement recommandé de maintenir à jour le noyau, votre système et tous les logiciels, car il bénéficie également de nombreux autres correctifs de sécurité.
Pour mettre à jour/mettre à niveau votre Arch Linux, exécutez :
$ sudo pacman -Syu
Pour mettre à jour Debian, Ubuntu :
$ sudo apt-get update && sudo apt-get dist-upgrade
Pour mettre à jour Fedora :
$ sudo dnf update
Pour mettre à jour RHEL/CentOS :
$ sudo yum update
Après avoir mis à jour votre système Linux, n'oubliez pas de le redémarrer.
Encore une fois, n'oubliez pas que ces problèmes ne sont pas encore complètement résolus. Vous devez continuer à mettre à jour vos systèmes Linux au cours des prochaines semaines, jusqu'à ce que tout soit réparé.
Suggestion de lecture :
- Comment accélérer le fonctionnement du système Linux sur les processeurs Intel