Faille Intel Foreshadow/L1TF : adieu l’hyperthreading …

EDIT du 31/08/2018: J’ai réécris l’introduction de ce billet décrivant la faille. Merci à Fabien pour m’avoir poussé à creuser un peu plus, car j’ai dit quelques bêtises auparavant ! Ceci étant, je ne suis pas à l’abris d’avoir laissé quelques coquilles, donc je vous conseille, pour plus d’infos au sujet de Foreshadow, d’ailler consulter les sites officiels.

Vous avez sans doute tous entendu parler récemment de la nouvelle faille hardware, dite “Foreshadow”, sur les processeurs Intel. Cette faille concerne en fait quasi tous les processeurs produits par la société depuis la deuxième génération de processeurs Core iX. Derrière Foreshadow se cache en fait 3 failles différentes mais utilisant les mêmes méthodes et ayant les mêmes effets : l’accès potentiel d’un processus non privilégié à des portions de mémoire protégées. La faille regroupe en fait trois CVE, CVE-2018-3615, CVE-2018-3620 et CVE-2018-3646. La méthode reste la même que pour Meltdown, trouver des failles dans le code du processeur afin de pouvoir avoir accès à des données en principe inaccessibles, présentes sur le cache L1. Foreshadow exploite encore le talon d’Achille des processeurs, très exposé en ce moment, le “Speculative Branch Execution”, mais aussi le système de gestion de pages mémoire (à la base des fonctions de swap de nos O.S.), d’où son nom technique “L1TF”. Allez voir la petite vidéo très intéressante chez RedHat qui explique ça assez clairement et simplement ici.

Cette nouvelle faille concerne aussi, pour les processeurs les plus récents, les enclaves sécurisés par SGX. La SGX est un jeu d’instructions spécifiques permettant à un programme non privilégié (User Level) de déclarer et exploiter une portion de la mémoire dans un mode protégé appelé enclave, impossible à lire par tout autre processus, y compris privilégié (Mode Kernel). Typiquement, les fonction SGX sont particulièrement utiles pour travailler sur des données cryptographiques dont on veut garantir la confidentialité. On comprend ici pourquoi c’est particulièrement sensible …

Ne nous laissons pas abattre et continuons …

En somme cette faille permet de contourner un paquet de protections mémoire implémentées par Intel dans tous ces processeurs depuis 10 ans, ni plus ni moins. Le problème, outre son existence évidemment, c’est que cette faille exploite aussi des faiblesses de la technologie Hyperthreading implantée par Intel et il semble, pour le moment en tout cas, qu’il soit nécessaire (mais pas suffisant) de désactiver cette fonction pour protéger un système des attaques potentielles. J’ai envie de dire … Gloups.

Or, comme vous le savez certainement, en environnement massivement mutualisé, l’Hyperthreading apporte un gain de puissance qui peut être non négligeable (jusqu’à 20/30% dans les cas les plus favorables), en fonction de la charge globale de chaque hyperviseur et le taux de consolidation vCPU/CPU physique.

VMware a bien entendu communiqué depuis quelques jours sur cette faille et la situation s’impose désormais à nous : si vous voulez mitiger le risque d’une exposition de vos environnements à cette faille, il va être nécessaire de désactiver l’hyperthreading sur vos serveurs ! La question suivante est évidente : quel impact sur les performances ?

Pour résumer, si vous avez un ratio vCPU/pCPU peu élevé et que vos hyperviseurs ont de la marge coté consommation CPU (+ de 25/30%), pas de souci à prévoir sur l’existant, mais mécaniquement, vous perdrez de la marge de consolidation. Si par contre, votre ratio vCPU/pCPU est assez élevé (supérieur à 1,5/2 disons) et que vos machines sont déjà pas mal chargées, attention, l’application des recommandations VMware pourrait vous faire franchir un seuil et générer avoir des impacts sur vos applications (celles sensibles à la latence sont particulièrement exposées).

Le KB#55767 détaille un peu plus ces impacts en fonction de différents scénarios. Dans tous les cas, je ne peux que vous recommander malgré tout la prudence avant toute mise en production de ce patch. Testez-le d’abord sur des environnements moins sensibles (pas forcément du test, d’ailleurs, qui pourrait ne pas être représentatif de la charge de production réelle). Envisagez aussi de le limiter aux hyperviseurs hébergeant des machines virtuelles que vous ne maîtrisez pas entièrement ou exposées aux tempêtes des internets. Le mieux, si vous pouvez vous le permettre financièrement, étant de ne pas prendre de risque et d’étendre d’au moins 15% vos capacités de virtualisation pour absorber la baisse de puissance moyenne induite. Merci qui ?

A priori et contrairement à Spectre/Meltdown au début de l’année, il semblerait que cette faille ne touche pas les autres constructeurs de processeurs, AMD,ARM et IBM Power. Par contre, toute cette nouvelle génération de failles hardwares depuis quelques mois maintenant a amené bon nombre de hackers à explorer de nouvelles voies “bas niveau” dans leur perpétuelle recherche de failles de sécurité ; nul doute que nous ne soyons pas au bout de nos surprise dans ce domaine… angoisse, angoisse.

Le KB#55767 chez VMware détaillant les impacts performance potentiels de L1TF : ici
Le KB#55806 chez VMware détaillant le process de remédiation sur vSphere, mais pas que : ici
Le site construit spécifiquement pour expliquer et discuter de la faille Foreshadow : ici
Un article de TrendMicro qui résume très bien la situation, à consulter ici.
L’information en français, publiée par OVH : ici.