GPUBreach: le RowHammer envahit la mémoire du GPU et pourrait prendre le contrôle de votre système

Ces derniers mois, la communauté de la sécurité a tourné les yeux vers une vieille connaissance : le RowHammer. Ce qui jusqu'à récemment semblait être un problème de mémoire majeur (DRAM) a maintenant fait un bond inquiétant vers des cartes graphiques haute performance, où les chercheurs universitaires ont montré des attaques pratiques capables non seulement de données corrompues, mais de l'escalade des privilèges et même de prendre le plein contrôle d'un système hôte.

RowHammer est un phénomène physique des mémoires dynamiques (DRAM) par lequel les accès répétés à une rangée de cellules génèrent des interférences électriques qui peuvent causer flips dans les rangées adjacentes, transformer les zéros en un ou vice versa et briser l'isolation garantit que les systèmes d'exploitation et le bac à sable supportent. La technique a été étudiée pendant des années et est documentée en ressources techniques générales telles que la référence sur RowHammer dans l'encyclopédie technique Wikipédia et dans plusieurs études universitaires et blogs spécialisés.

Dans le domaine graphique, la mémoire GDDR6 - utilisée par de nombreux GPU modernes - introduit de nouveaux vecteurs et défis. Des recherches récentes nommées GPUHammer, GPUBreach, GDDRHammer et GeForge décrivent comment un attaquant peut induire des retournements binaires dans la mémoire du GPU et en tirer profit contre les structures critiques du système graphique, comme les tables de page du GPU. Un pas de plus que les attaques précédentes : il ne se limite pas à des résultats de calcul dégradants, mais peut devenir un levier pour un accès arbitraire à la mémoire et, dans des cas extrêmes, des privilèges scalés au niveau du CPU.

L'œuvre connue sous le nom de GPUBreach est particulièrement frappante car elle montre qu'en modifiant les entrées dans les tables de pages GPU (PTE), un processus sans privilèges peut obtenir des capacités de lecture et d'écriture arbitraires sur la mémoire du GPU. Ce qui est inquiétant, c'est la chaîne de fonctionnement qui peut être suivie : cet accès manipule les structures que le GPU utilise pour émettre l'accès direct à la mémoire CPU (DMA) et si à ce moment-là il y a des vulnérabilités de sécurité dans le contrôleur du fabricant - par exemple des erreurs de sécurité dans le pilote du noyau NVIDIA - l'opération peut aboutir à augmenter les privilèges à un shell avec des droits de gestion.

Un élément clé pour atténuer les attaques DMA est l'OIMMU, un composant matériel conçu pour isoler l'accès direct des périphériques à la mémoire du système. Cependant, les chercheurs montrent qu'il ne suffit pas que l'OIMMU soit activée : par des états corrompus considérés comme de confiance dans les tampons que l'OIMMU autorise, il est possible d'induire des écritures en dehors des limites du noyau qui évitent ces protections et ouvrent la porte à l'engagement total du système. Cela a des implications directes pour l'infrastructure cloud avec des GPU partagés, des déploiements multi-tenus orientés vers l'IA et des centres de calcul haute performance.

Les variantes GDDRHammer et GeForge travaillent sur des idées connexes - manipuler la traduction des adresses GPU via RowHammer flux en GDDR6 - et aussi réussir à convertir ces flips en lecture / écriture accès à l'espace mémoire de l'hôte. En termes techniques, ils diffèrent à quel niveau de l'arborescence de page ils exploitent (par exemple dernier niveau de PTE par rapport à un autre niveau de répertoire), mais l'objectif est co-incident: enlever la traduction pour élargir la portée du code malveillant exécuté dans le GPU.

En plus du risque de contrôle du système, un autre impact déjà démontré a à voir avec les modèles d'apprentissage automatique: les attaques basées sur ces défaillances peuvent fortement dégrader la précision des modèles qui sont exécutés en GPU, avec des effets qui ont significativement réduit la précision de l'interférence dans les expériences. Le risque d'exposition de documents confidentiels, comme les clés cryptographiques utilisées dans les librairies sur la plate-forme GPU elle-même, a également été observé.

Que peut-on faire aujourd'hui? À titre de mesure temporaire, activer la correction d'erreur matérielle (ECC) dans les GPU qui la supportent réduit la probabilité que des retournements isolés se traduisent en corruption exploitable, mais n'est pas une solution infaillible. Il existe des schémas d'attaque qui induisent de multiples retournements simultanés - au-delà de la capacité de correction d'ECC - et, comme l'ont montré des recherches antérieures sur la tolérance d'ECC, la correction peut être insuffisante ou générer une corruption silencieuse dans des scénarios spécifiques. Dans les GPU de bureau ou portables où ECC n'est pas disponible, les options sont encore plus limitées.

La réponse à long terme passe par plusieurs façons : les fabricants devront appliquer des correctifs aux conducteurs et aux sapins, resserrer la validation et les limites des tampons gérés par le noyau, et travailler avec la communauté académique pour identifier et atténuer de nouvelles formes d'attaque. Les opérateurs de cloud et ceux qui gèrent les grappes de charge IA devront repenser les politiques de partage du matériel, appliquer des contrôles plus stricts sur le code accéléré GPU et envisager la segmentation physique ou le dévouement des ressources pour les charges de confiance. La NVIDIA, pour sa part, gère un centre de sécurité où elle publie des avis et des recommandations. votre portail de sécurité.

Cette vague de résultats rappelle que la surface de l'attaque évolue à mesure que la technologie se spécialise et s'étend. Ce qui a commencé comme une curiosité dans DRAM devient une menace pratique pour les infrastructures critiques qui dépend de l'accélération par GPU. L'interaction entre les fonctionnalités matérielles (telles que la RDA6 et l'OIMMU), les logiciels complexes (drivers de noyau) et les modèles de partage de cloud crée des vecteurs d'exploitation qui nécessitent une réponse coordonnée entre les milieux universitaires, l'industrie et les opérateurs.

Si vous voulez approfondir le phénomène RowHammer et examiner les travaux académiques et pré-impression connexes, une référence utile pour explorer les articles et les dépôts est le moteur de recherche pré-impression pour arXiv et pour suivre les groupes de recherche, il est recommandé de consulter les portails des ministères comme celui de l'Université de Toronto, où bon nombre de ces contributions sont publiées ( Université de Toronto - CS).

Bref, GPUBreach et les techniques connexes sont un rappel fort: la sécurité matérielle compte autant que les logiciels. L'industrie doit accélérer les correctifs et les mesures d'atténuation, et les gestionnaires de systèmes devraient revoir les pratiques de déploiement et d'isolement afin de réduire les risques dans les environnements où les GPU sont des ressources essentielles.