Intel, des failles (ter)

Non, il ne faut pas croire que cela m'amuse de recenser les failles matérielles sur les processeurs (Intel ou autre). Au contraire : cela m'inquiète au plus haut point, sans m'étonner outre mesure, car la complexité des processeurs est devenue telle qu'il devient quasi-impossible de maîtriser l'ensemble de sa conception. En sécurité informatique, plus c'est complexe, plus c'est dur à sécuriser.

Nouvelle faille : Foreshadow

Traduisons ce qu'on trouve sur le site dédié (rappel : un site dédié avec un joli nom de faille et un beau logo sont les minimum syndicaux pour toute faille qui se vend respecte).

Foreshadow is a speculative execution attack on Intel processors which allows an attacker to steal sensitive information stored inside personal computers or third party clouds. Foreshadow has two versions, the original attack designed to extract data from SGX enclaves and a Next-Generation version which affects Virtual Machines (VMs), hypervisors (VMM), operating system (OS) kernel memory, and System Management Mode (SMM) memory.

Foreshadow est une attaque de type exécution spéculative (comme Spectre et Meltdown) touchant les processeurs Intel (les pauvres !) permettant à un attaquant de dérober des informations sensibles stockés sur des ordinateurs personnels ou dans le cloud (il est écrit third party, mais en vérité cela touche toute infrastructure, interne ou externe, cloud ou pas, qui compte sur un hyperviseur de virtualisation pour isoler des environnements et des machines, cf juste en dessous).

Foreshadow a deux versions : l'attaque originale, conçue pour extraire des données des enclaves SGX (censées justement éviter cela...) et une nouvelle génération "NG" (de l'attaque) qui affecte les machines virtuelles, les hyperviseurs VMM (Virtual Machine Manager, hyperviseur utilisé dans le cloud Azure), la mémoire du noyau du système d'exploitation et la mémoire utilisée par le mode "management de système" (SMM).

Encore du Meltdown ?

Foreshadow est une variante de Meltdown[1], de type exécution spéculative, dont la source a fini par être identifiée par Intel dans le cache L1 (L1TF, L1 Terminal Fault). Hélas, une fois ce constat réalisé, Intel a remarqué que cela avait d'autres conséquences[2], d'où la création de deux variantes appelées "NG".

Composants impactés

Virtual Machines Manager

Les bulletins ne sont pas très clairs sur ce point, car ils parlent de VMM sans trop de précision. D'après ce qu'en dit OVH[3], les failles touchent bien les hyperviseurs en général, et non uniquement le VMM d'Azure.

Système d'exploitation

Idem pour l'OS, quasiment jamais mentionné dans les publications. Toutefois Linux est bel est bien touché lui aussi, cf les publications des différents éditeurs. Il n'y a pas que Windows...

System Management Mode

Il s'agit d'un mode spécial d'exécution du processeur, dont les caractéristiques sont :

  • Se situe dans une mémoire spéciale et séparée (SMRAM) ;
  • Peut accéder à l'ensemble du système et des entres/sorties, y compris la mémoire de l'OS et d'un hyperviseur ;
  • Est appelé par une interruption spécifique (SMI, System Management Interrupt) ;
  • Possède un gestionnaire logiciel (SMI handler) pour exécuter des opérations basées sur différentes SMI.

C'est un peu technique mais en gros ça signifie qu'il s'agit d'un mode qui a accès à tout, et qu'on l'imagine réservé pour un usage spécifique et bien délimité.

SGX

SGX est une enclave sécurisée, présente dans certains processeurs Intel, et conçue pour que personne ne puisse venir y lire le contenu : cela permet de cacher des informations très sensibles, comme des clés de chiffrements, dans une infrastructure tierce.

Conditions d'exploitation

Maigre consolation : la faille se situe au niveau core, c'est-à-dire qu'un processus ne peut utiliser cette vulnérabilité que contre un autre processus s'exécutant sur le même cœur du processeur[4]. Cela concerne les processeurs récents (ce qui est le cas de tous les processeurs SGX), de génération Sandy Bridge ou suivantes, car Intel assigne un cache L1 dédié pour chaque cœur[5].

Logiquement, avec un processeur 4 cœurs, il n'y a qu'une chance sur 4 de subir l'attaque, et il est peu probable (impossible ?) pour un processus, qui plus est lancé dans une machine virtuelle, de choisir le processeur sur lequel il s'exécute.

Multiplié par le nombre de cœurs et de machines virtuelles, la probabilité baisse encore, surtout que la difficulté sera surtout de réussir à exécuter le programme d'attaque sur le même cœur de processeur que la cible. Après, une machine virtuelle peut demander à s'exécuter sur plusieurs processeurs virtuels, donc sur plusieurs cores, mais ça se paye. Et dans un environnement mutualisant des milliers de processeurs, ça peut devenir coûteux.

Correctifs

On peut renforcer l'isolation par les mesures suivantes :

  • En s'assurant qu'un core n'est pas partagé entre plusieurs machines virtuelles en même temps ;
  • Lorsque deux machines se suivent séquentiellement sur un core, alors on s'assure que le cache L1 est bien effacé ;
  • En ayant un environnement dédié (hyperviseur dédié chez AWS) pour empêcher le partage des CPU.

En ce qui concerne SMM, une mise-à-jour de microcode et de firmware semble nécessaire[6].

Sinon désactiver l'hyperthreading est un moyen (coûteux à mon avis) d'empêcher l'exploitation de la faille ; on ne le réactivera qu'avec précautions, mais tout cela est bien expliqué sur le site de Xen.

Liens utiles

Sur Linux

RedHat propose une présentation rapide de Foreshadow, assez bien faite.

Liens internes

Site officiel

Références

  1. (en) Jo Van Bulck et al., « Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution » [PDF], sur foreshadowattack.eu,
  2. (en) Ofir Weisse et al., « Foreshadow-NG: Breaking the Virtual Memory Abstraction with Transient Out-of-Order Execution » [PDF], sur foreshadowattack.eu,
  3. OVH, « OVH - L1 Terminal Fault (L1TF) / Foreshadow disclosure », sur OVH Blog, (consulté le 21 août 2018)
  4. « Protecting against the new “L1TF” speculative vulnerabilities », sur Google Cloud Blog (consulté le 21 août 2018)
  5. (en) Yuval Yarom et al., « Mapping the Intel Last-Level Cache » [PDF], P. 3 (2.3 The Sandy Bridge last-level cache design)
  6. (en) « XSA-273 - Xen Security Advisories », sur xenbits.xen.org (consulté le 21 août 2018)
Foreshadow.jpg