Les GPUs sont aujourd’hui dans des millions d’appareils. Nous savons que la sécurité des CPUs est nécessaire car le CPU dirige totalement la machine dans son intégralité, les défenses logiciels ne sont pas nécessaires contre des attaques hardware. Or, les GPUs ont le droit de lire la mémoire que le CPU lit et plusieurs vulnérabilités ont été présentes dans nos GPUs, et bien plus qu’on ne le croit. Un autre problème de sécurité se trouve au niveau de la documentation des GPUs, elle est souvent trop pauvre comme sur Nvidia, et cela peut mener à des attaques informatiques, mais les vendeurs ne veulent pas exposer les architectures internes de sorte à pouvoir changer leur système de façon à invalider les systèmes basés sur des GPUs.
Voici un exemple sur l’exploitation de la mémoire partagée (CVE-2016-2067), considérons un environnement GPU intégré :
Alors par sécurité, le IOMMU est semblable au MMU du CPU, sauf qu’il est limité dans la mémoire qu’il peut accéder. La faille de sécurité fournit par cette CVE est le fait que le driver graphique de Adreno cartographie les pages mémoires en read-only par le CPU mais en writable par le GPU. Pour les GPUs discrets, il est possible de penser qu’il est plus complexe d’accéder à la mémoire RAM du CPU, l’utilisation de l’IOMMU est optionnelle et configurée par l’OS.
Source: Zhiting Zhu, Sangman Kim, Yuri Rozhanski, Yige Hu, Emmett Witchel, and Mark Silberstein. 2016. Understanding The Security of Discrete GPUs
Nous allons vous présenter une attaque DMA (Direct Memory Access) du GPU à la mémoire physique CPU en utilisant l’IOMMU. Pour accéder à la mémoire CPU, il faut que le CPU map une région mémoire dans l’espace mémoire du kernel GPU, une fois mappée, le GPU pourrait directement accéder à la mémoire du CPU mappée par DMA. Un problème qui peut arriver c’est de réécrire le code du kernel qu’on exécute, imaginons que le code kernel est trop grand : il ne peut donc pas rentrer entièrement dans I-Buffer et donc doit être stocké sur la RAM GPU, et donc réécrire dynamiquement le code kernel en utilisant une matrice d’addition et un process d’update. L’updater process n’aura qu’à localiser le code kernel dans la mémoire physique du GPU. Ceci est arrivé sur le driver PixelVault, celui-ci tournait indéfiniment, ce qui donne au process updater assez de temps pour localiser le driver en mémoire et changer son code, on pouvait aussi spéculer son espace mémoire.
Aussi, après l’exécution d’un kernel, rien ne garanti la RAZ des registres ! En utilisant cette technique on peut attaquer des kernels, et ceci permet une attaque à terme de rétro-ingénierie et même de compromission de données confidentielles, par exemple nous pourrions lire la clef de chiffrement d’un programme de sécurité, ceci a été effectué sur SSLShader, un programme qui accélère le calcul SSL sur GPU. Les chercheurs ont réussi à exploiter la fonction de chiffrement symétrique AES utilisée par SSLShader en retrouvant la clef. Et les architectures Fermi et Kepler de Nvidia ont été vulnérables à cette attaque.
Il est aussi possible d’exploiter des buffer overflow sur la heap (le tas) sur les kernels GPUs, en effet, le GPU basé sur CUDA se programme en C++, des attaques par COOP (Counterfeit Object-Oriented Programming) sont possibles, comme par exemple en réécrivant un pointeur vtable (fonction virtuelle).
Un problème d’aujourd’hui c’est qu’ASLR, la protection visant à randomiser les adresses de la pile d’exécution et du tas n’est pas implémenté dans les GPUs. Dans un CPU, lors d’une résolution d’adresse par un processus, celui-ci doit passer par la table des pages pour que l’adresse virtuelle redirige vers une adresse physique unique.
Source: Vulnerability analysis of GPU computing Michael Patterson
Nos GPUs n’implémentent ni le concept de mémoire virtuelle, ni ASLR. Donc 2 processus peuvent pointer vers la même adresse physique. On pourrait croire que comme le GPU exécute un kernel à la fois ceci ne pose pas de problème, or, cela veut dire que les appels à par exemple cudaMalloc retournent la même adresse, et qu’à la fin d’un processus, les données ne sont pas RAZ !
Source: Vulnerability analysis of GPU computing Michael Patterson
Et étant donné qu’il n’y a pas de concept de mémoire virtuelle, cela veut dire que nous pouvons faire fuir un énorme nombre de données. Il n’y a pas de protection mémoire hardware dans nos GPUs. Dans le cas où un kernel ne libère pas la mémoire allouée, nous pourrions avoir accès à l’ensemble de la heap !
Enfin, le GPU contient le framebuffer : c’est-à-dire l’image courante qu’affiche notre ordinateur, cela veut dire qu’un malware peut aisément utiliser le GPU pour espionner.