(modifié le 18 janvier 2018 à 0:11)

Vous vous êtes peut-être demandé pourquoi aucun billet n'a été publié sur Meltdown / Spectre ici même. 2 raisons : le sujet est complexe à appréhender car il touche au matériel et j'ai préféré attendre d'avoir suffisamment d'information pour vous les synthétiser ici.

J'ai diffusé toutes les informations au fil de l'eau sur twitter et sur le salon #securite_exploits sur discord.

De quoi parle-t-on ?

Meltdown signifie la fusion, entre l'espace utilisateur et le noyau.

Spectre signifie hanter, car avec une faille de conception matérielle cela risque d'être le cas pendant un bon moment.

Comme c'est difficile à expliquer par écrit, voici 2 vidéos en français :

Meltdown est une vulnérabilité qui nécessite d'avoir un accès local à une machine, du moins pour l'instant.

Pour Spectre on entends parler d'exploitation à distance via JavaScript ou WebAssembly pas d'exploit diffusé pour l'instant.

Ces vulnérabilités se traduisent par l’existence de 3 CVE ou variantes :

  • Spectre Variante 1 : CVE-2017-5753 "bounds check bypass" (Intel, AMD, ARM)
  • Spectre Variante 2 : CVE-2017-5715 "branch target injection" (Intel, AMD, ARM)
  • Meltdown Variante 3 : CVE-2017-5754 "rogue data cache load" (Intel uniquement)

Pour connaitre les détails techniques c'est sur la blog Google Project Zero ainsi que sur le site dédié.

Si vous adorez les aspects hardware et optimisations CPU alors je vous renvoie vers le billet de Pixis sur HackAndDo et chez OVH.

Quelles solutions ?

Concernant Spectre Variante 1 à l'heure actuelle l'unique solution efficace est le remplacement du processeur (coucou Intel qui vient juste de sortir sa 8ème gen au CES), bien que des solutions de mitigation voient le jour.

Si Google affirme pouvoir se protéger de la variante 2 grâce à retpoline (une option de compilation introduite dans le compilateur gcc) couplé à une mise à jour du microcode CPU il ne propose aucune solution pour la variante 1 mais précise que l'exploitation est très difficile. L'ensemble des distributions va profiter de retpoline mais il va falloir recompiler les applications.

Concernant la variante 3 c'est un correctif au niveau du noyau du système d'exploitation qui permet de s'en prémunir. Pour le noyau Linux on parle de KPTI (Kernel Page Table Isolation). En supprimant des optimisations spéculatives ce correctif impacterait les performances, même si Google semble pondérer :

Il existe de nombreux rapports contradictoires sur les effets des patchs qui font l'objet de discussions publiques. Dans certains cas, les gens ont publié des résultats de tests qui se concentrent uniquement sur les appels API vers le système d'exploitation, ce qui ne représente pas le scénario réel que les logiciels clients rencontreront. Il n' y a pas de substitut aux tests pour déterminer par vous-même le rendement auquel vous pouvez vous attendre dans votre situation réelle. Nous croyons qu'il existe des solutions qui ont un impact minimal sur les performances, et nous nous attendons à ce que ces techniques soient adoptées par les éditeurs de logiciels au fil du temps. Nous avons conçu et testé nos mesures d'atténuation pour que ce problème ait un impact minimal sur le rendement, et le déploiement s'est déroulé sans incident (traduction libre)

Microsoft pour sa part détaille les  baisses de performance attendues en fonction de la version de Windows et de la génération de votre CPU sur votre Desktop. Pour Windows Server Microsoft évoque :

Pour toute application à forte intensité d'E/S on constate un impact de performance plus important lorsque vous activez les mesures d'atténuation pour isoler le code non fiable dans une instance Windows Server. C'est pourquoi vous devez être attentif à évaluer le risque de code non fiable pour chaque instance Windows Server, et à équilibrer le compromis entre sécurité et performance pour votre environnement.

Globalement les 3 variantes auront des impacts

Que faut-il mettre à jour ?

Toute la chaine nécessite d'être mise à jour, à savoir :

  • BIOS
  • hyperviseur
  • système d'exploitation

Si vous avez une infra VMware par exemple, il ne suffit pas de mettre à jour la version ESXi pour s'en protéger, car il sera toujours possible de passer théoriquement d'une VM à une autre tant que toutes les VM ne sont pas patchées.

Sur notre discord tuxfanou précise :

La mise à jour hôte empêche aux VM d'aller lire la mémoire des autres VM.
La mise à jour VM permet d'empêcher la lecture mémoire dans le guest OS lui même.
La mise à jour du BIOS permet de combler la faille niveau CPU (en complément des patchs logiciels, pas en remplacement)

Cela signifie aussi que si vous hébergez des OS obsolètes pour des raisons de compatibilité métier il est temps de déplacer ces VM sur des hyperviseurs isolés. C'est à dire sur des serveurs ESXi dédiés pour ces OS troués et en ajoutant idéalement un pare-feu n'autorisant que les services nécessaires à être accessibles. Si vous n'avez pas l'infrastructure pour insérer un pare-feu entre votre réseau et ce cluster dédié alors il faut à minima activer le pare-feu natif au système de la VM (cf note technique ANSSI).

Le cas des antivirus sous Windows

Si le patch sur les OS basés sur Linux ne semble pas faire de vague on ne peut pas en dire autant pour Microsoft.

Pour fonctionner de façon efficace et proactive les solutions antivirus sont très proches du noyau. En modifiant son fonctionnement le patch peut créer des comportement inattendus qui se traduisent par des plantages (BSOD).

Microsoft a décidé d'appliquer le patch via Windows Update uniquement sur les machines Windows ayant un antivirus compatible. Pour s'annoncer comme compatible l'antivirus doit ajouter une clé de registre dont voici le reg :

Si la clé n'existe pas le correctif Meltdown ne s'installe pas mais Microsoft vient d'annoncer qu'aucune autre correctif n'arrivera ensuite, tel que le patch tuesday publié le 09/01/2018 qui contient justement le correctif.

La liste des antivirus compatibles, que ce soit du desktop ou du endpoint, est disponible dans ce document (merci à Kevin Beaumont).

Les KB chez Microsoft

Voici les différents KB :

  • Windows 7 et 2008 R2 : KB4056894
  • Windows Server 2012 R2 : KB4056898
  • Windows Server 2016 : KB4056890
  • Windows 10 1709 : KB4056892
  • Windows 10 1703: KB4056891
  • Windows 10 1608: KB4056890
  • Windows 10 1511: KB4056888
  • Windows 10 1507 : KB4056893

Complément chez Barkly.

Et les guides associés :

Liens très utiles

Voici les communiqués par techno :

OS Variante 1 Variante 2 Variante 3
VMware CVE-2017-5753 / 5715 - CVE-2017-5715
Debian CVE-2017-5753 CVE-2017-5715 CVE-2017-5754
RedHat CVE-2017-5753 CVE-2017-5715 CVE-2017-5754
Ubuntu CVE-2017-5753 CVE-2017-5715 CVE-2017-5754
En attente En attente de publication des patchs

Pour le reste :

Pour vérifier l'état d'application des patchs sur GNU/Linux : script github / forum ubuntu / pour arch.

Enfin, le SECHebdo du 09/01/2018 qui m'a aidé dans la compréhension de certains éléments techniques :

Et NoLimitSecu :

Conclusion

Bref, il va falloir faire le tour de tous vos équipements contenant des processeurs : serveurs, routeurs, smartphone, pare-feux. Cela n'est pas sans nous rappeler Heartbleed ou WannaCry.

Côté client je vous conseille d'utiliser Firefox qui contient déjà la mitigation depuis la 57.0.4. Pour les navigateurs basés sur Chromium une isolation sera activée prochainement dans la version 64 (activable manuellement en 63) et avec IE/Edge c'est patché avec le patch tuesday du 09/01/2018. Vous pouvez aussi utiliser NoScript si vous avez peur des attaques JS, avec les inconvénients que cela amène...

Les Raspberry Pi eux ne sont pas touchés de part leur processeur, et ça c'est déjà une bonne nouvelle dans tout ce bordel 🙂

N'hésitez pas à corriger toute coquille / erreur / imprécision en commentaire.

bonus : le pétage de câble de Linus Torvalds qui vaut des points

Auteur : Mr Xhark

Fondateur du blog et passionné par les nouvelles techno, suivez-moi sur twitter