Take A Way : une faille de sécurité découverte chez AMD, mais démentie par l'entreprise

Avec la déferlante de vulnérabilités concernant majoritairement Intel, il est devenu clair aujourd’hui qu’aucun processeur n’était à 100 % sécurisé. Les puces étant conçues par des humains faillibles (et les codes encore loin d’être prouvés formellement), trouver une vulnérabilité est à coup sûr possible quel que soit le modèle, tant que vous disposez de suffisamment de moyens et de temps. Avec l’exécution spéculative non protégée, Intel a cherché à écraser la concurrence en effectuant des optimisations plus poussées que l’état de l’art, à savoir effectuer des traitements sur des données non certifiées. Le futur a montré que cela était trop dangereux... et ce sont les bleus qui se sont retrouvés à porter le chapeau.

Un petit souci, amédé ?

Néanmoins, puisqu’AMD est en train de se redorer le blason, il parait logique que les recherches en sécurité aillent de plus en plus de leur côté, et, comme vous l’aurez compris en premier paragraphe, trouvent également de quoi fuiter par-ci par-là. C’est en tout cas ce qui semble se produire avec Take A Way, une vulnérabilité découverte en août 2019, et rendue publique il y a quelques jours. Au niveau des auteurs, citons la présence d’une chercheuse de l’IRISA (un groupe de recherche de l’Université de Rennes, en France) et un groupe en provenance de l’université de Graz, en Autriche.

En effet, en manipulant le mécanisme servant à associer à une adresse mémoire le way du cache L1-D — une organisation logique de ce dernier permettant de retrouver plus rapidement l’endroit de la donnée — il devient possible de retrouver la présence d'une opération effectuée sur cette cellule mémoire. Pour cela, les chercheurs ont conçu deux mécanismes : d’un côté, Collide+Probe permet de surveiller les accès à une certaine adresse mémoire virtuelle (comprenez, en ne sachant pas à quoi elle correspond) en forçant un conflit au niveau du prédicateur de way, puis en mesurant le temps d’accès au cache. De l’autre, Load+Reload force l’éviction de la donnée en cas d’accès, permettant une nouvelle fois moyennant chronométrage de remonter à l’utilisation ou non de la zone mémoire. Au niveau des conditions d’utilisation, la première technique peut être utilisée tant que les programmes partagent le même cœur logique, là où la seconde se contentera de deux processus tournants sur le même cœur physique (SMT ou ordonnancement faisant passer le programme attaquant et sa cible sur le même cœur).

Au niveau des applications, le papier reste bien fourni : des simples droits d’exécution utilisateur permettent de remonter jusqu’à des clefs AES, de fragiliser grandement le mécanisme ASLR de protection du noyau, remontant jusqu’à un hyperviseur, et cela parfois à partir de simple code JavaScript exécuté sur un navigateur récent. Néanmoins, les informations fuitées restent plus partielles que Spectre et Cie : il est impossible de récupérer le contenu mémoire d’une adresse arbitraire, ce qui rend la faille bien moins critique.

Au niveau des processeurs affectés, comptez grosso modo tout le parc : n’importe laquelle puce depuis 2011 jusqu’aux dernières Zen2 en passant par les déclinaisons EPYC pour serveurs. Pour plus de détails, voici un petit récapitulatif issu du whitepaper :

L’affaire aurait pu en rester là avec un énième correctif - possible selon les chercheurs, sans étude plus poussée sur les performances - sauf qu’AMD n’est pas vraiment de cet avis-là. Dans un communiqué officiel, les rouges affirment en effet que le comportement du cache nécessite un canal auxiliaire déjà connu, et patché de surcroît. Et nous ne pouvons pas vraiment leur donner tort : Spectre est bel et bien utilisé dans un de leur exemple, celui permettant de faire fuiter une partie de la mémoire du noyau. Notez bien l’absence de jugement sur la nouveauté et la véracité du travail de déduction du comportement du prédicateur du cache : la firme veille au grain sur ses technologies ! Bien sûr, les chercheurs maintiennent leurs allégations, de telle sorte que l’affaire commence à tourner au sac de nouilles.

De plus, le premier auteur n’est pas vraiment à son coup d’essai, puisqu’il avait déjà travaillé sur les fameuses failles Spectre et Meltdown, tout comme Rowhammer, Zombieload et Fallout ! Autant dire que l’attaquant a du crédit, bien plus que l’obscure CTS Labs sorti de nulle part en mars 2018. Comment expliquer alors la divergence de fait entre la firme et les chercheurs ? Un problème de communication ? Une volonté de garder une image de marque propre face au concurrent amoindri ? Impossible de se positionner à l’heure actuelle, mais cela devrait se clarifier sous peu. Affaire à suivre ! (Source : Tom’s Hardware)