Petit aparté sur le monde matériel
- Retour aux basiques
- Concrètement, où se trouve la faille ?
- Comment le cloud provider peut-il protéger ses clients ?
- Conclusion
Dans notre précédent article, nous avons évoqué les failles qui peuvent affecter le matériel physique, car bien que nous parlions d’informatique « dans les nuages » ou de réseau distribué sur des milliers de serveurs dans le monde, ceux-ci se trouvent toujours, à un moment donné, dans le monde physique : des data centers contenant de vastes baies – ou « armoires », ce qui correspond mieux à leur aspect physique – dans lesquels sont « rackés » (entendre par là rangés dans des espèces de tiroirs) des serveurs… Qui ne sont rien de plus que des ordinateurs vaguement similaires aux vielles tours que nous avons à la maison.
Quand nous parlons de serveurs physiques, ceux-ci sont équipés de processeurs, et ceux-ci peuvent être victimes de failles jouant sur le fonctionnement même de ces processeurs… Il y a de cela quelques années, j’ai eu l’occasion de me pencher sur deux failles en particulier : Meltdown et Spectre, pour en étudier le fonctionnement, le problème qu’elles posaient pour le Cloud, et comment nous pourrions nous en prémunir.
Retour aux basiques
Quand nous parlons de processeurs, nous voyons cette pièce de silicium dense et compact, capable de traiter des milliards d’opérations chaque seconde. Nous parlons de « CPU » pour les unités de calcul, de « GPU » pour les cartes graphiques (et maintenant l’IA, qui exploitent les méthodes de calcul des GPU à leur profit), et d’autres types de processeurs suivant leurs spécialités.
Mais lorsque nous revenons un peu en arrière dans le temps, nous avons l’occasion de comprendre l’organisation logique de ces unités. Le principe de base repose en effet sur des composants capables de réaliser des opérations binaires : calculer des opérations entre des 0 et des 1, aboutissant à des résultats entre 0 et 1.
Pour que ces opérations puissent se réaliser, le processeur a besoin d’un espace de mémoire dédié, le cache, pour retrouver les données à manipuler, les opérations à exécuter, et y stocker le résultat, ce qui constitue en quelque sorte notre programme. Plus les processeurs sont capables de traiter d’opérations, plus il est nécessaire d’augmenter la capacité de ce cache : collé au processeur, spécialisé sur la rapidité d’accès, il permet de garantir la performance grâce à laquelle nous pouvons jouer à des jeux toujours plus sophistiqués, ou réaliser des traitements toujours plus complexes.
Concrètement, où se trouve la faille ?
Dans les CPU modernes, nous trouvons plusieurs processeurs. Ils contiennent aussi plusieurs niveaux de cache (souvent trois) du plus rapide et petit au plus volumineux et lent. Les premiers sont au plus proche du processeur auquel ils sont dédiés, tandis que les derniers sont partagés entre plusieurs processeurs. Ceux-ci contiennent donc potentiellement plusieurs programmes en mémoire, car ceux-ci peuvent être exécutés chacun par un processeur différent.
Pour ces architectures, les CPU disposent d’algorithmes pour deviner les prochaines instructions. Lorsque le processeur exécute un programme, il tombe très souvent sur des boucles – l’exécution d’un même bout de code en faisant varier certains paramètres – ou des conditions – choisir entre plusieurs alternatives en fonction des paramètres d’entrée.
Lorsque cela se produit, le processeur peut tenter de deviner quelle sera la prochaine instruction à exécuter et la charger en avance dans le cache du plus bas niveau, cette petite zone de mémoire ultra rapide au plus proche du processeur.
Et c’est là que Meltdown et Spectre rentrent dans la danse
Ces failles permettent au pirate de jouer sur ces optimisations du processeur pour injecter du code malveillant. Meltdown est un exploit grâce auquel un pirate est en mesure d’obtenir un accès illégitime à la mémoire du système, comme s’il forçait l’accès d’une tour de contrôle. Spectre, de son côté, consiste à jouer sur les prédictions du processeur pour qu’il exécute un bout de code pirate à la place du code légitime.
Lorsque le pirate joue bien son coup (et il faut un certain talent), il peut récupérer les données sensibles (comme un mot de passe) du programme. En effet, lorsque nous arrivons au niveau du cache, ces données ne sont plus chiffrées (sinon le processeur ne pourrait pas les traiter). Et forcément, elles sont exposées.
Que se passe-t-il, dans un contexte de virtualisation ?
Un CPU donné est généralement partagé entre plusieurs machines virtuelles. Celles-ci sont traitées comme des programmes par leur hôte, l’hyperviseur en charge de l’orchestration de ces machines virtuelles. Bien souvent dans le cloud – notamment le cloud public – ces machines appartiennent à plusieurs utilisateurs différents. Donc si notre pirate utilise une machine virtuelle sur le même hyperviseur que sa cible, il finira tôt ou tard par récupérer quelques données utiles.
Comment le cloud provider peut-il protéger ses clients ?
Fort heureusement, il dispose de tout un arsenal de solutions permettant de mitiger le problème. Dans notre précédent article, nous avons déjà parlé des enclaves numériques.
Les hôtes dédiés
Une première solution, radicale, consiste à proposer aux clients les plus demandeurs de sécurité une offre d’hôte dédié (dedicated host). Cette solution est radicale, car elle garantit au client d’être seul utilisateur de l’hyperviseur (le fameux « host » dédié). Elle a cependant un coût, car l’hyperviseur réservé ne peut être utilisé que par un seul client. S’il ne remplit pas tout l’espace disponible avec ses VMs, le reste est gaspillé. Et son coût se traduit par un supplément sur la facture du client.
Attacher la machine virtuelle au processeur
Une autre solution, plus complexe à mettre en place, mais moins coûteuse, repose sur ce qu’on appelle le pinning. Un processeur donné est réservé à une Machine Virtuelle donnée, et donc à un client donné. Cette solution n’est pas parfaite (souvenez-vous : le cache plus volumineux partagé entre plusieurs processeurs), mais fournit un niveau de garantie généralement acceptable.
Patcher le processeur
Une dernière solution concerne les patchs proposés par les fabricants pour protéger les processeurs. Ceux-ci doivent être appliqués au niveau du matériel, et offrent des améliorations du comportement des processeurs, spécifiquement pour pallier à ces failles.
Malheureusement, ils entraînent des ralentissements du système, car ils impliquent de sacrifier certaines des optimisations du processeur. Par exemple, le système de prédiction sera moins ambitieux, et donc moins performant.
Sécuriser les traitements… dès le démarrage du système
Les cloud providers peuvent également mettre à disposition de leurs clients des options grâce auxquelles ceux-ci peuvent protéger les partitions de démarrage de leur machine virtuelle, en exploitant des composants physiques sur les hyperviseurs. Par exemple, le SecureBoot est une fonctionnalité de l’UEFI (le premier programme chargé au démarrage d’une machine, qu’elle soit physique ou virtuelle) permettant de garantir que tous les composants et configurations impliqués dans la chaîne de démarrage du système sont fiables.
Un module de plateforme sécurisée (le TPM, pour « Trusted Platform Module ») peut également être implémenté sous la forme d’une puce physique intégrée aux appareils pour agir comme une enclave sécurisée renforçant la sécurité de nos VM. C’est donc une mécanique très proche de ce que nous avons vu dans notre précédent article.
Conclusion
Se protéger contre les failles au niveau du matériel nécessite des solutions qui seront soit des contournements, soit très coûteuses à mettre en place. Parfois, le matériel physique doit être tout simplement remplacé, car la faille atteint directement le processeur ou d’autres composants des machines physiques. D’autre part, de nouvelles failles peuvent voir le jour. Dans les cas de Meltdown et Spectre, nous avons par exemple eu ZombieLoad, qui avait trouvé une faiblesse dans les correctifs, forçant les experts à constamment innover pour protéger les processeurs.
Heureusement, les probabilités qu’un pirate réussisse à obtenir des données sensibles via cette faille (et précisément celles qui l’intéressent) sont suffisamment réduites pour épargner des sueurs froides à la plupart d’entre nous.
Mais comprendre ces niveaux d’enjeux, qui descendent jusqu’au plus bas niveau, nous rappelle que s’appuyer sur des machines physiques dont nous n’avons pas la connaissance – et donc pas la maîtrise – reste une faille potentielle à notre souveraineté numérique.
Write a comment