Spectre : des bugs en série dans les correctifs

Des correctifs contre Spectre

Après l’annonce de la découverte des deux failles de sécurité Spectre et Meltdown, Intel a publié des solutions pour combler ces brèches, notamment Spectre. Ainsi, le but d’Intel était de mettre en place des correctifs de microcode, diffusés grâce au fondeur. C’est à dire grâce à la mise à jour des serveurs (enfin de leurs BIOS). Et donc de publier des versions de Linux et Windows sécurisées et mises à jour.
Ces microcodes devaient mettre en place trois processus de sécurité afin de contrer Spectre :

  • L’IBRSIndirect Branch Restricted Speculation : ce mécanisme protège le noyau d’exécuter l’ordre qui vient du cache infecté par une application en mode utilisateur.
  • IBPBIndirect Branch Prediction Barrier : réinitialisation de l’état de la prédiction de branchement.
  • STIBPSingle Thread Indirect Branch Prediction : empêche un thread qui fonctionne sur un coeur CPU d’utiliser les données de prédiction d’un autre thread tournant sur ce même coeur.

Donc ces mécanismes devaient s’exécuter grâce aux noyaux modifiés des systèmes d’exploitation. Puis, ils étaient supposés freiner les exploitations hypothétiques de la variante de Spectre.

Des microcodes pas si performants

Ainsi, la stratégie était en place et devait fonctionner comme sur des roulettes. Néanmoins, les premiers retours ont été plus que mitigés. En effet, les utilisateurs ont remonté des bugs comme des démarrages intempestifs des serveurs. Ou encore l’impossibilité de démarrer des serveurs exécutant Xeon E3 et E5 v3 et v4.
Pourtant, Intel avait précisé que les Xeon récents (Scalable Plateform Skylake) n’auraient pas à craindre de problèmes éventuels. Sauf que finalement, Intel a dû diffuser un communiqué annonçant le contraire, bien que des correctifs étaient en cours de création.
Et malgré ce travail et ces correctifs en préparation, on peut s’interroger sur le sérieux de cette situation. En effet, les constructeurs et particulièrement Intel ont déjà eu beaucoup de temps pour travailler sur la résolution de ces problèmes ! D’autant plus qu’Intel avait d’abord tenté de minimiser Spectre et Meltdown, puis d’avoir sous-estimé la situation. De plus, beaucoup de rumeurs sur les forums font penser que d’autres failles de sécurité à l’image de Spectre pourraient voir le jour dans un futur proche…
Meltdown Spectre bugs Intel Cybersecurity

Trop de bugs tue le bug

Ainsi, les mises à jour de BIOS sont peu à peu retirées des sites de téléchargement.
De plus, les éditeurs, pour lutter contre ces Spectre et Meltdown, avaient inclus ces derniers microcodes Intel ainsi que leurs correctifs. Mais ils se voient obligés de les retirer précipitamment au vu des bugs constatés !
Même si de nouveaux microcodes rectifiés vont bientôt voir le jour, les utilisateurs risquent de leur réserver un accueil glacial. Voire même d’attendre avant de les exécuter, lassés des bugs à répétition. Néanmoins, ce comportement les rend vulnérables face à d’éventuelles cyberattaques … Ainsi, Red Hat prescrit à ses clients de prendre contact avec les fabricants de serveur. Ainsi, ils pourront avoir les nouvelles mises à jour de BIOS. Et pourront donc installer les futurs correctifs pour Spectre 2.

Retpoline

Pour pallier aux déboires d’Intel, Google a développé la technique Retpoline, afin de contrer la variante de Spectre, Spectre 2. Pour l’exécuter, il faut mettre à jour les compilateurs avec Retpoline ainsi qu’une décompilation des noyaux, des packages et apps afin de parer les attaques Spectre.
Et même si des noyaux compilés avec la MAJ de GCC, ce n’est pas assez. En effet, il faudrait recopier l’écosystème entier des applications afin d’être vraiment protégés.
Aujourd’hui, des correctifs pour GCC et LLVM sont à disposition, mais nous devrons quand même attendre le temps que Retpoline s’étende aux compilateurs commerciaux. Ainsi qu’à tous les langages du marché.
Donc pendant que l’écosystème des applicatifs se « Retpoline« , nous devons continuer à appliquer les correctifs de microcodes dès leur sortie. Et Intel n’est pas le seul. En effet, AMD propose aussi des correctifs microcodes, et IBM et Oracle y travaillent aussi pour leurs puces Power, Z et Sparc.

Partagez l'article

Partager sur facebook
Partager sur twitter
Partager sur linkedin
Partager sur email