COMPTOIR
register

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.

 

amd broken logo

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 :

 

takeaway affected cpu

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)

 

Un poil avant ?

Windows Insider 19577 : révision de la télémétrie et de Powertools

Un peu plus tard ...

Test • ASRock RX 5500 XT Phantom Gaming

Les 6 ragots
Les ragots sont actuellement
ouverts à tous, c'est open bar !
par Nicolas D., le Mardi 10 Mars 2020 à 01h21  
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes le Lundi 09 Mars 2020 à 19h35
En gros:
Collide+Probe: Même Logical Core car c'est une collision d'adresse virtuelle (avec des adresses physiques différentes), or les adresses virtuelles des deux thread d'un core sont isolés probablement avec des tag. (c'est ce que suggère le papier dans la partie 3.3)
Load+Reload: Même physicial Core car c'est une collision d'adresse physique. C'est à dire qu'une même adresse physique est aliasé depuis 2 adresses virtuelles différentes (sur les 2 threads par exemple), or le cache ne peut pas gérer ce cas, il ne peut ne garde qu'un seul des alias à la fois.
C'est détaillé dans la partie 4.

Et dernier détail important c'est que ces side-channels permettent une très grande précision temporelle et une débit d'extraction d'information très rapide. c'est peut-être même les plus rapides connues.
Tu as totalement raison, merci pour cette précision, c'est corrigé ! N'oublie pas qu'il existe un petit bouton "Signaler un truc" réservé spécifiquement à cet usage !
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Lundi 09 Mars 2020 à 19h35  
Et petit detail:
 
. Au niveau des conditions d'utilisation, la première technique peut être utilisée entre cœurs du même die

Non, c'est sur un même core logique, donc sur le même thread, c'est a dire un processus qui laisse la main a l'autre puis qui reprend la main.

En gros:
Collide+Probe: Même Logical Core car c'est une collision d'adresse virtuelle (avec des adresses physiques différentes), or les adresses virtuelles des deux thread d'un core sont isolés probablement avec des tag. (c'est ce que suggère le papier dans la partie 3.3)
Load+Reload: Même physicial Core car c'est une collision d'adresse physique. C'est à dire qu'une même adresse physique est aliasé depuis 2 adresses virtuelles différentes (sur les 2 threads par exemple), or le cache ne peut pas gérer ce cas, il ne peut ne garde qu'un seul des alias à la fois.
C'est détaillé dans la partie 4.

Et dernier détail important c'est que ces side-channels permettent une très grande précision temporelle et une débit d'extraction d'information très rapide. c'est peut-être même les plus rapides connues.
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Lundi 09 Mars 2020 à 18h17  
par Un ragoteur bio occitan d'Occitanie le Lundi 09 Mars 2020 à 17h56
Dire que Spectre est corrigé, oui, par soft (OS) et en partie par micro code (dans la puce si mise à jour).
Mais toutes les boitent ne mettent pas à jour le microcode du processeur puisque ne mettent pas à jour le bios/UEFI qui fait se taf là, sauf pour appeler el support du fabricant.
AMD part du principe qu'une série de patchs sont disponible, cela ne veut pas dire qu'ils sont effectifs partout.
Ce n'est pas tellement le sujet je trouve. Si tu ne met pas à jour tes firmwares/logiciels/OS et/ou que tu désactives les patchs alors AMD (ou Intel) n'est pas responsable des problèmes que tu as. Et ce que tu dit est indépendant de l'existance de ces 2 nouveaux side channels.

D'ailleurs la réponse de AMD (1) c'est précisément un rappel qui consistent à dire : mettez tout à jour, codez de la bonne manière, et mettez les patchs.
Ou autrement dit: Si vous ne le faites pas on est pas responsable, et pas de nouveau patch prévu pour cela car on ne nous a pas montré de scénario aujourd'hui qui peuvent exploiter ces side channels avec tous les patchs/fix activés.

(1) : https://www.amd.com/en/corporate/product-security
par Un ragoteur bio occitan d'Occitanie, le Lundi 09 Mars 2020 à 17h56  
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes le Lundi 09 Mars 2020 à 14h26
En faite AMD répond un peu comment Intel le fait ici. Ils n'observent que les exemples de scénarios attaques qui ont été monté dans le papier.
[..]
Les deux ont raison sur le fond. Mais les uns ont plutôt une vision sur le futur (les chercheurs) qui anticipe un futur problème et propose des solutions.
Et les autres (entreprise) ont une vision plus pragmatique de la chose, ils attendent des attaques réels pour le prendre au sérieux. "Oui il y a un trou dans le bateau que l'on avait pas vu. Mais l'eau ne rentre pas donc on n'y touche pas !"

Notez que Intel réagit de la même manière c'est une réaction propre aux entreprises.
Les patchs OS sont désactivables avec un petit droit admin sur une VM par exemple, et après tu peux remonter sur l'hyperviseur.
Pour l'utilisateur lambda c'est pas spécialement grave (patch et pas d'utilisation de VM (donc pas vraiment touché ) et surtout, il a peu de secret important pour quelqu'un avec ce niveau d'expertise, sauf cas très rare.
Pour les pro c'est totalement autre chose, sans compter les mécanismes de protection sur AWS, GCP, Azure qui deviennent caduc et où tu peux récupérer les clés de chiffrements dans tous les sens. Perdre la clé mettre un un système PKI c'est comment dire... "oups..."

Dire que Spectre est corrigé, oui, par soft (OS) et en partie par micro code (dans la puce si mise à jour).
Mais toutes les boitent ne mettent pas à jour le microcode du processeur puisque ne mettent pas à jour le bios/UEFI qui fait se taf là, sauf pour appeler el support du fabricant.
AMD part du principe qu'une série de patchs sont disponible, cela ne veut pas dire qu'ils sont effectifs partout.
par LeRagoteurNormand en Île-de-France, le Lundi 09 Mars 2020 à 14h27  
C'est l'université de Rennes et pas Renne

Merci à toute l'équipe du comptoir pour vos supers articles
par Une ragoteuse à forte poitrine en Auvergne-Rhône-Alpes, le Lundi 09 Mars 2020 à 14h26  
 
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à.
En faite AMD répond un peu comment Intel le fait ici. Ils n'observent que les exemples de scénarios attaques qui ont été monté dans le papier.
Or dans le papier les exemples de scénarios attaques sont des scénarios connues et déjà corrigés il faut désactiver les patchs pour pouvoir réalisé les exemples.
Donc effectivement AMD a raison, les attaques montré dans le papier sont déjà patché.

Mais le point des chercheurs c'est que les exemples données ne sont pas là pour montrer qu'ils arrivent à casser toutes les sécurités du système chez AMD, ils ne font que présenter deux nouveaux side channels (Collide+Probe & Load+Reload) et montrent leur faisabilité sur des anciennes failles déjà connues.

Le but des chercheurs est de montrer que les side-channels dont ils parlent ne sont pas que théorique, ils sont réalisable peut importe le scénario d'attaque.
Alors que AMD ne s'intéresse pas aux side-channels mais aux scénarios mis en place seulement.

Les deux ont raison sur le fond. Mais les uns ont plutôt une vision sur le futur (les chercheurs) qui anticipe un futur problème et propose des solutions.
Et les autres (entreprise) ont une vision plus pragmatique de la chose, ils attendent des attaques réels pour le prendre au sérieux. "Oui il y a un trou dans le bateau que l'on avait pas vu. Mais l'eau ne rentre pas donc on n'y touche pas !"

Notez que Intel réagit de la même manière c'est une réaction propre aux entreprises.