COMPTOIR
register

Une faille de plus sur les processeurs AMD comme Intel : les spectres des muOPs mortes sont de retour !

Avec la tonitruante découverte des vulnérabilités Meltdown et Spectre, un grand pan de la microarchitecture moderne a volé en éclat. En effet, alors que l’on considérait jusqu’alors que la spéculation sur des données non vérifiées ne posait aucun problème, voilà que des scientifiques ont prouvé le contraire en extrayant à partir des traces restantes d’exécutions annulées des informations allant jusqu’au... contenu complet de la RAM. Suivant cette méthode d’abus du processeur en entraînant à tort la prédiction afin de charger spéculativement tout et n’importe quoi, de nombreux autres travaux ont vu le jour, changeant principalement le canal auxiliaire par lequel fuitent les informations, ainsi que la méthode de spéculation.

 

Le travail du jour se place dans la même veine : réalisé par des chercheurs de l’University of Virginia et l’University of California, San Diego, cette faille nommée « I See Dead μops » consiste cette fois-ci à abuser du cache des micro-Ops. De quoi s’agit-il, exactement ? En interne, les processeurs doivent décoder une à une les instructions x86 composant un programme en micro-Ops (ou µOPs) : une opération coûteuse du fait de l’ancienneté de la chose, et de choix de design qui se sont révélés malheureux par la suite. Heureusement, ces problèmes sont la plupart du temps masqué par une mise en cache des instructions déjà décodées, qui se retrouve — chez Intel comme chez AMD — dans un µOP cache, parfois appelé Loop Stream Buffer (du fait que les µOPs décodées ne sont réutilisées... que dans le cas de boucles).

 

i see dead uops cdh

Le comptoir des profa facile vous accueille tous les trolldredi, à Kotte-Le-Zoute !

 

Un des soucis réside dans le fait que la politique de remplacement de ce cache est optimisée pour les performances : les µOPs conservées en priorité sont celles des boucles exécutées le plus grand nombre de fois, et non les dernières récupérées. Rajoutez une histoire d’inclusivité avec les caches parents (L1-I et I-TLB) permettant de retirer pour sûr des instructions du cache en remplissant l’un des parents, et vous obtenez une situation propice à la transmission d’informations par canal auxiliaire : deux threads peuvent se passer des informations via l’état du µOP cache ; et, dans le cas d’AMD seulement, deux hyperthreads partageant le même cœur physique — chez Intel, ce cache est divisé de manière statique entre les deux cœurs logiques : aucune information ne peut fuiter. Nos vecteurs d’attaques étant définis, il ne reste qu’à utiliser une mauvaise prédiction pour charger conditionnellement certaines µOPs dans le cache en fonction d’une donnée mémoire protégée, et utiliser votre méthode de « réception » d’information pour en déduire sa valeur.

 

Avec un accès décomposé bit par bit, mais pourtant une vitesse 3 fois plus grande que celle des failles originales (notamment du fait d’une latence bien plus faible du µOP cache par rapport au cache de données utilisé dans les Spectre et Meltdown initiaux), la faille a de quoi faire froid dans le dos, d’autant plus qu’une rustine risque de coûter lourd en performance, puisque limitant la spéculation ou vidant le µOP cache lors d’accès mémoires protégés. Par contre, un doublement de ce cache afin de séparer les µOP protégées des µOPs non protégé pourrait être effectué à l’avenir, limitant ainsi grandement les risques sans pour autant les annuler totalement... et en réduisant le taux d’utilisation du cache.

 

Cependant, gardez en tête que ces mécanismes ne peuvent être utilisés que si l’attaquant possède les droits d’exécution sur votre machine, ce qui n’est plus possible si vous utilisez un navigateur web à jour du fait d’un timer rendu volontairement suffisamment imprécis pour éviter toute exploitation en JavaScript de ces attaques. Reste que, pour les serveurs et les VM en location, une telle faille n’est clairement pas souhaitable... Un argument de plus pour vendre du matériel mis à jour ?

 

Un poil avant ?

3,5 milliards de $ rien que pour Foveros chez Intel au Nouveau-Mexique !

Un peu plus tard ...

Test • Asus PN62

Les 18 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Jeudi 06 Mai 2021 à 15h54  
par Jemporte, le Jeudi 06 Mai 2021 à 01h31
Ca c'est ce qu'ils spéculent qu'il est possible de faire. Il faudrait encore le prouver.
J'imagine que ça oeuvre dur un peu partout dans ce sens maintenant que la news est tombée.
... Non, ils l'ont prouvé dans un PoC.. C'est ecrit dans le papier, mais comme toujours tu parles sans savoir.

Ce qui n'est pas prouvé c'est qu'il existe des bouts de code dans Linux ou dans d'autre OS ou d'autre type d'application qui peuvent aujourd'hui être vulnérable à une attaque avec cette stratégie. Mais que cela soit le cas ou non, le papier reste une avancé car il montre que le micro-op cache est utilisable pour un transfert d'information, ce qui questionne la fiabilité des stratégies de mitigation employé contre Spectre/Meltdown et tout le reste.

Et par ailleurs, c'est aujourd'hui totalement possible d'utiliser ce covert channel pour faire discuter deux programmes sur une machine qui ne devraient pas pouvoir, et ceci de manière presque indétectable.
par Jemporte, le Jeudi 06 Mai 2021 à 01h31  
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Mardi 04 Mai 2021 à 23h03
Oui, donc tu n'as rien compris du tout en faite.

Le but c'est définir un nouveau covert channel, c'est à dire un canal de communication qui n'est pas prevu par le CPU.
Puis produire une attaque avec la même stratégie que Spectre/Meltdown ou autre:
Avec de l'exécution spéculative (ou n'importe quelle effet de transient execution) faire lire à la microarch des données qu'elle ne devrait pas. Ce qui ne serait normalement jamais utilisable par l'attaquant car la microarch annule cette exécution quand elle détecte que c'est un chemin d'exécution invalide.
Mais le papier montre qu'on peut utiliser ce nouveau covert channel pour exfiltrer ces données avant qu'elles soient annulés par la microarch. Ce qui rend ces données volées accessible à l'attaquant. Ça permet de lire la mémoire du kernel par exemple.

Il n'est pas question de mesurer les micro-ops exécutés par une victime en guise d'attaque, il est question d'utiliser le cache de micro-op comme canal pour un transfert d'information qui ne devrait pas être possible.
Ca c'est ce qu'ils spéculent qu'il est possible de faire. Il faudrait encore le prouver.
J'imagine que ça oeuvre dur un peu partout dans ce sens maintenant que la news est tombée.
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Mercredi 05 Mai 2021 à 12h20  
par Un ragoteur pragmatique embusqué, le Mercredi 05 Mai 2021 à 10h10
Vous pouvez accéder aux données traitées (et donc aux pages mémoire correspondantes) par d'autres programmes tournant sur le même coeur (puisqu'il faut que les caches soient partagés entre les programmes pour monter le canal parallèle), mais c'est tout !
Oui si tu cibles que l'hyperviseur tu ne peux pas dump toute la mémoire du CPU, mais tu peux dump la mémoire de tous les OS qui tournent sur cet hyperviseur. Et en théorie il n'est pas impossible de viser l'OS au dessus de l'hyperviseur et donc de dump toute la mémoire du CPU. Ce qui bloque réellement ce scénario c'est qu'il faut trouver le bon chemin d'exécution si il en existe un.

C'est la force de ce type d'attaques, elles brisent tous les mécanismes d'isolation software ou virtualisé par le hardware. Tout ce qui reste c'est l'isolation réellement physique, c'est à dire quand le cache est réellement partitionné statiquement en 2 par exemple.
par Un ragoteur pragmatique embusqué, le Mercredi 05 Mai 2021 à 10h10  
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Mardi 04 Mai 2021 à 22h43
Le kernel à accès a l'ensemble de la mémoire donc potentiellement tu peux dump toute la mémoire du serveur depuis un seule coeur.
Pas dans une VM, non !!!

Le noyau d'une VM n'a même pas accès à certains modes superviseurs (ou "rings", chez Intel) du CPU !

Vous pouvez accéder aux données traitées (et donc aux pages mémoire correspondantes) par d'autres programmes tournant sur le même coeur (puisqu'il faut que les caches soient partagés entre les programmes pour monter le canal parallèle), mais c'est tout !
par Un énarque des ragots des Pays de la Loire, le Mercredi 05 Mai 2021 à 08h17  
par xenesys, le Mardi 04 Mai 2021 à 12h44
J'ai sûrement pas tout compris mais vider le cache de la boucle ou écraser les plus anciennes données tous les x cycles, ne pourrait pas limiter les problèmes de fuite ?
une action de plus par cycle, tu perde 40% de performances
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Mardi 04 Mai 2021 à 23h03  
par Jemporte, le Mardi 04 Mai 2021 à 20h00
D'après ce que j'ai compris du papier, cette attaque permet de récupérer dans le cache l'info des micro-ops utilisées par "autrui" en faisant fi des privilèges. La belle affaire. Ca demanderait un proof of concept sur l'utilité, même si par déduction on peut arriver à choper des choses.
Oui, donc tu n'as rien compris du tout en faite.

Le but c'est définir un nouveau covert channel, c'est à dire un canal de communication qui n'est pas prevu par le CPU.
Puis produire une attaque avec la même stratégie que Spectre/Meltdown ou autre:
Avec de l'exécution spéculative (ou n'importe quelle effet de transient execution) faire lire à la microarch des données qu'elle ne devrait pas. Ce qui ne serait normalement jamais utilisable par l'attaquant car la microarch annule cette exécution quand elle détecte que c'est un chemin d'exécution invalide.
Mais le papier montre qu'on peut utiliser ce nouveau covert channel pour exfiltrer ces données avant qu'elles soient annulés par la microarch. Ce qui rend ces données volées accessible à l'attaquant. Ça permet de lire la mémoire du kernel par exemple.

Il n'est pas question de mesurer les micro-ops exécutés par une victime en guise d'attaque, il est question d'utiliser le cache de micro-op comme canal pour un transfert d'information qui ne devrait pas être possible.
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Mardi 04 Mai 2021 à 22h43  
par Un ragoteur pragmatique embusqué, le Mardi 04 Mai 2021 à 17h46
Attention: une VM est elle-même virtualisée dans un hyperviseur: il faudrait parvenir à remonter du noyau virtualisé sous la VM (ou d'un programme en ring 0 tournant dessus) à l'hyperviseur, et de là remonter au noyau du système hôte, qui lui tournerait (dans ma proposition) sur un coeur différent de la VM), puis de redescendre dans l'hyperviseur d'une autre VM (celle que vous souhaitez pirater), elle-même tournant sur un autre coeur; cela me semble diablement acrobatique... et donc fort improbable.
Pour faire ce type d'attaque tu n'as pas besoin de "redescendre". Tu as "juste" à trouver un bout de code du kernel/hyperviseur vulnérable et l'exploiter pour dumper la mémoire. Le kernel à accès a l'ensemble de la mémoire donc potentiellement tu peux dump toute la mémoire du serveur depuis un seule coeur.

Cela dis c'est clairement pas facile, et rien ne dit que c'est possible, le papier n'aborde pas le sujet des VM. Ils ne proposent même pas de vrai cas d'utilisation dans un contexte réel car l'attaque est très complexe. Et a mon sens le vrai but de ce genre de papier est surtout de montrer que les choix fait pour mitiger les vulnérabilités de type spectre et metldown sont en realités pas des solutions très fiable.
Ils parlent dans un chapitre des autres vecteurs d'attaques, a savoir tous les composants stateful avec un effet mesurable sur le timing et partagé par plusieurs processus. Les composants stateless sont aussi utilisables mais c'est plus difficile.
Ce genre de papier questionnent globalement la notion d'isolation lorsque des compsants du CPU sont partagés
par Jemporte, le Mardi 04 Mai 2021 à 20h00  
D'après ce que j'ai compris du papier, cette attaque permet de récupérer dans le cache l'info des micro-ops utilisées par "autrui" en faisant fi des privilèges. La belle affaire. Ca demanderait un proof of concept sur l'utilité, même si par déduction on peut arriver à choper des choses.
par Un ragoteur pragmatique embusqué, le Mardi 04 Mai 2021 à 17h46  
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Mardi 04 Mai 2021 à 16h02
Mais ils parlent bien d'une attaque "across the user/kernel privilege boundary" donc je doute fortement qu'une VM te protège réellement.
Attention: une VM est elle-même virtualisée dans un hyperviseur: il faudrait parvenir à remonter du noyau virtualisé sous la VM (ou d'un programme en ring 0 tournant dessus) à l'hyperviseur, et de là remonter au noyau du système hôte, qui lui tournerait (dans ma proposition) sur un coeur différent de la VM), puis de redescendre dans l'hyperviseur d'une autre VM (celle que vous souhaitez pirater), elle-même tournant sur un autre coeur; cela me semble diablement acrobatique... et donc fort improbable.
par dfd, le Mardi 04 Mai 2021 à 17h16  
Pour les problèmes de fuites, Papa Jensen de Nvidia a la solution !
Sisi je l'ai vue sur Le Comptoir pas plus tard qu'hier...
par ragoteur prédicteur embusqué, le Mardi 04 Mai 2021 à 17h10  
Comme toujours ces failles ont peu d'intérêt pour le hackeur à attaquer un particulier pour essayer de récupérer son historique de navigation et ses liens pr0n sur des BX sévèrement équipées niveau pot d'échappement, c'est surtout et principalement les systèmes pro qui seront visés.
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Mardi 04 Mai 2021 à 16h02  
par Un ragoteur pragmatique embusqué, le Mardi 04 Mai 2021 à 15h24
Pour les VM, une solution serait de dédier un ou plusieurs coeurs physiques (donc deux virtuels par coeurs physiques si SMT) à chaque VM sur le serveur.
Cela empêche l'exploitation de ce type de failles par des tiers auxquels la VM n'appartient pas.
C'est pas évident de savoir précisément ce qu'on peut faire dans une VM avec cette faille. Ils n'en parlent pas dans le papier il me semble.
Mais ils parlent bien d'une attaque "across the user/kernel privilege boundary" donc je doute fortement qu'une VM te protège réellement.

Mais faut pas oublier que l'attaque est surtout théorique, ils ne proposent pas d'exemple d'attaque avec du code réellement utilisé aujourd'hui car les conditions pour mettre en œuvre l'attaque sont quand meme très difficile à atteindre