Meltdown sur AMD : une faille découverte chez les rouges ?

Si vous ne connaissez pas Meltdown, il s’agit d’une chaîne de bars bien branchés orientée jeux vidéos et pop culture, dont la succursale parisienne date de 2012. Une entreprise visionnaire, puisque son nom a été par la suite propagé et popularisé par une série de failles désormais longue comme le bras visant à altérer un état microarchitectural afin d’un faire un canal de communication imprévu. Si cela peut être tout bonnement inutile, il suffit qu’un programme sensible y laisse des traces pour que la chose devienne sérieuse, ce qui peut aller jusqu’à la mise à mal de toute la sécurité d’un système.

Jusqu’à présent, l’entreprise la plus touchée est sans aucun doute Intel, non pas que ses produits soient significativement moins sécurisés que les autres, mais plutôt du fait des implémentations encore trop basse performance d’ARM pour être concernée, et d’un AMD en retrait sur le plan des parts de marchés, et donc sur la recherche en cybersécurité. Pour autant, les cartes sont constamment rebattues, et voilà que les tendances s’inversent, avec une croissance progressive des rouges sur les datacenters... et donc sur la recherche qui y est associée. Est-ce donc vraiment une surprise de voir une nouvelle faille de la série Meltdown sur matériel rouge uniquement ? La réponse se situe dans la question ; et c’est ainsi davantage dans le coût au niveau performance qu’il faut se plonger.

Revenons d’abord sur la vulnérabilité en elle-même : découverte par deux chercheurs de l’École polytechnique royale de Dresde et reconnue par AMD, la nouvelle venue est également répertoriée sur la base de données CVE, à la place 2020-12965. Son exploitation se base sur le système de pagination de la mémoire, qui n’effectue dans un premier temps qu’une vérification sur les 48 premiers bits d’une adresse, chargeant ainsi spéculativement une adresse potentiellement invalide, en laissant de sales traces aux endroits habituels, cache L1D en particulier. Néanmoins, le composant responsable se nomme TLB, et est vidé lors des changements de contexte entre processus : le seul scénario d’attaque concerne un programme faisant tourner plusieurs threads, dans lequel l’un d’entre eux, vérolé, pourrait accéder à des zones privées des autres threads.. un endroit peu utilisé en programmation pour stocker des informations critiques. Pas du plus effrayant dit comme cela, d’autant plus que les chercheurs n’ont pas trouvé de cas applicables en pratique, en particlieur pas dans le noyau Linux.

Exploitée artificiellement sur des processeurs Zen et Zen2, la faille a tout de même permis de soutirer 125 octets par secondes : pas beaucoup, certes, mais suffisant pour chouraver une clef cryptographique sans être repéré. Notez que les CPU Intel vulnérables au Microarchitectural Data Sampling sont également touchés, mais la faille est encore moins intéressante de leur côté du fait d’autres vulnérabilités plus faciles à exploiter.

Au niveau des correctifs, AMD conseille aux programmeurs de « vérifier leur code » à la recherche d’applications possibles de cette technique, et d’y pallier selon un guide déjà tout prêt depuis les précédentes vulnérabilités — ou une barrière mémoire. Une solution potentiellement coûteuse en performances, et l’on imagine difficilement une entreprise distribuer spécifiquement des binaires patchés AMD et non Intel... Cependant, vu la difficulté d’exploitation, il est fort probable que rien ne change, tout du moins pour le moment : ouf ! (Source : Tom’s Hardware)