GPU.zip - attaque de vol de pixels par canal auxiliaire basée sur le web

• Une attaque capable d’exfiltrer les pixels d’autres pages web dans les navigateurs basés sur Chromium disposant d’un GPU.
  • Elle déduit les pixels affichés en exploitant une optimisation de compression des données graphiques transparentes présente dans le GPU.
  • Pour que l’attaque fonctionne, la page web visée doit être intégrée dans la page malveillante via un iframe, ou inversement la page malveillante doit être intégrée dans la page visée via un iframe, entre autres possibilités.
• La plupart des GPU peuvent être affectés, y compris les GPU Nvidia ainsi que les GPU intégrés d’AMD, Apple et Intel.
  • Les chercheurs fournissent en démonstration un exemple permettant d’identifier le nom d’un utilisateur connecté à Wikipedia depuis une page web malveillante.
• Selon le GPU, le taux de réussite de l’attaque atteint environ 96 %.
  • Toutefois, comme l’inférence doit se faire pixel par pixel, récupérer l’ensemble des pixels affichés prend beaucoup de temps (de 30 à 200 minutes).
• Cette vulnérabilité a été signalée aux fournisseurs en mars 2023, mais aucun correctif n’a encore été déployé.

[kuroneko]

• Fil HN
• Article
• Code

J’imagine qu’ils profitent du délai entre le signalement de la faille et sa divulgation publique pour préparer un joli nom et un logo...?

Quoi qu’il en soit, c’est assez fascinant.

À cause du mécanisme de compression graphique du GPU, de légères différences apparaissent lors du rendu,
et ces différences permettraient de déduire les pixels de la zone compressée concernée (4x4 ou 8x8).

ps.
« ou lorsqu’une page web malveillante est insérée dans la page web ciblée via un iframe, etc. » <- ce point n’est pas très clair...
En tout cas, il semble que l’attaque soit possible dans le cas où « la page web ciblée est insérée dans une page web malveillante via un iframe ».

[kuroneko]

Résumé IA du fil HN

• vessenes : salue la prouesse technique de cette attaque, mais la considère moins comme quelque chose d’élégant que comme une démonstration de force d’ingénierie soigneusement réfléchie. Il souligne qu’elle fonctionne en exploitant la différence de temps de traitement GPU entre les pixels sombres et les pixels clairs.
• twelvechairs : se demande pourquoi le correctif proposé ne consiste pas simplement à ne pas autoriser l’insertion d’iframes intersites, puisque d’autres navigateurs adoptent cette approche.
• chatmasta : propose comme compromis d’introduire un indicateur CSP ou d’exiger un opt-in pour les filtres SVG sur les sites chargés en iframe. Il s’interroge sur les cas d’usage, qu’il juge peu clairs, nécessitant des filtres SVG dans des iframes cross-origin.
• kevingadd : souligne que même sans accélération matérielle, les filtres SVG peuvent toujours exposer un side channel de données temporelles, donc le GPU n’est pas la cause fondamentale.
• stuaxo : propose la « loi d’Axson » selon laquelle toute optimisation suffisamment rapide finit par être détournée en vecteur d’attaque.
• vacuity : estime que des problèmes comme Spectre apparaissent quand on pousse trop loin la performance, et appelle à écrire un article intitulé « optimisations considérées comme nuisibles ».
• pests : note que la reconstruction des pixels sur un portable AMD Ryzen a pris 30 minutes avec une précision de 97 %, tandis qu’un Intel i7 a nécessité 215 minutes.
• anfilt : pense que le véritable problème se situe dans le navigateur, car seul Chromium est affecté, et non le GPU en lui-même.
• stalfosknight : est d’accord pour dire qu’il faut y voir un exploit Chromium plutôt qu’un problème GPU, puisque les autres navigateurs y sont immunisés.

Résumé IA de l’article

Ce livre blanc examine la compression logicielle transparente des données graphiques effectuée par les GPU intégrés (iGPU) des processeurs Intel et AMD. Comme cette compression s’applique même lorsqu’elle n’est pas explicitement demandée par le logiciel, il est difficile pour les développeurs de la refuser.

Les auteurs présentent des éléments montrant l’existence d’une compression basée sur iGPU au moyen d’expériences suivant le trafic DRAM et les temps de rendu avec différents motifs graphiques. Ils constatent que cette compression induit un comportement dépendant des données dans l’utilisation de la DRAM et l’occupation du cache.

Par rétro-ingénierie, ils montrent que les algorithmes de compression utilisés dans les iGPU Intel et AMD récents diffèrent selon le fournisseur et ne sont pas documentés. Les GPU Intel tentent de représenter une fenêtre de 4x8 pixels avec une seule ligne de cache, tandis que les GPU AMD tentent de représenter une fenêtre de 8x8 avec 1 à 3 lignes de cache.

L’article démontre une attaque moderne de vol de pixels cross-origin contre les versions récentes de Google Chrome. En générant des motifs très redondants ou non redondants selon les pixels secrets, un attaquant peut inférer les valeurs de pixels via les effets de compression iGPU dépendants des données sur le trafic DRAM et le temps de rendu.

Cette recherche remet en cause l’idée reçue selon laquelle la compression peut être considérée comme purement logicielle, et attire l’attention sur des techniques de compression subtiles et non documentées qui ont des implications en matière de sécurité et de confidentialité via des side channels. Elle souligne également la nécessité de mitigations logicielles face aux fuites d’information involontaires provoquées par les optimisations matérielles.