Dernièrement, je suis tombé sur un article de Korben portant sur Meltdown et Spectre : SpeculationControl - Un module PowerShell anti-Spectre / Meltdown. C’est marrant comme le temps passe vite : ces failles ont été rendues publiques en 2018, et à l’époque, j’avais profité d’un sprint break pour étudier leur fonctionnement, le problème qu’elles posaient pour le Cloud, et comment nous pourrions nous en prémunir.\ L’exercice était vraiment sympa, et rien que pour la nostalgie, je vais vous vulgariser au mieux ce que j’ai retenu de Meltdown et Spectre, et comment ça se passe dans le Cloud.

Comme l’a très bien expliqué Korben, Spectre et Meltdown sont deux failles jouant sur les prédictions des processeurs modernes.

Concrètement, de quoi s’agit-il ?

Dans les CPU modernes, on trouve plusieurs processeurs. il contiennent aussi plusieurs niveaux de cache (souvent trois) du plus rapide et petit aux plus volumineux et lents. Les premiers sont au plus proche du processeur auxquels 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.

C’est pour ces architectures que 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 (exécution d’un même bout de code en faisant varier certains paramètres), ou des conditions.

Lorsque ça se produit, le processeur peut tenter de deviner quelle sera la prochaine instruction à exécuter et la charger en avance dans le cache, 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 :

Ils permettent au pirate de jouer sur ces technos pour injecter du code malveillant …\ Meltdown, c’est un exploit qui permet à un pirate 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, par contre, consiste à jouer sur les prédictions du processeur pour qu’il exécuter 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. Typiquement, quand on arrive au niveau du cache, ces donnés ne sont plus chiffrées (sinon le processeur ne pourrait pas les traiter). Forcément, elles sont exposées.

Que se passe-t-il, dans un contexte de virtualisation ?

Eh bien un CPU donné est généralement partagé entre plusieurs Machines Virtuelles, qui sont traité comme des programmes par leur hôte (l’hyperviseur). Elles appartiennent bien souvent à 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 chopper 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.\ 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 garantie 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.\ 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.\ Une dernière solution concerne les patchs proposés 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 palier à ces failles. Malheureusement, ils entraînent des ralentissements du système, car elles impliquent de sacrifier certaines des optimisations du processeur (typiquement, le système de prédiction est moins ambitieux, et donc moins performant).

Conclusion

Comme l’a bien rappelé Korben, les solutions pour se protéger de Meltdown et Spectre sont soit des contournements, soit coûteuse. D’autre part, de nouvelles failles de la même famille ont vu le jour, dans les années suivantes (comme ZombieLoad, par exemple), forçant les experts à constamment innover pour protéger les processeurs.\ Cependant, 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 🤗