
Preuve de concept d'élévation de privilèges locale exploitant les IOCTL de Gigabyte gdrv3.sys pour écrire le jeton SYSTEM dans un processus utilisateur via une lecture non vérifiée de la mémoire physique.
salut les hackers.
gdrv3.sys est le pilote noyau signé qui est livré avec Gigabyte App Center et EasyTune. Il crée \.\GIOV3 sans descripteur de sécurité, donc n'importe quel utilisateur local peut l'ouvrir sans admin, sans UAC. Deux de ses IOCTL résument toute l'histoire.
Le premier (0xC3502019) est censé lire la mémoire physique. Vous lui donnez une adresse physique, une longueur et un pointeur de sortie, et il copie les octets à cet endroit. Le pointeur de sortie est le problème : le pilote ne vérifie jamais qu'il s'agit de l'espace utilisateur. Pas de ProbeForWrite, pas de vérification de limites, rien. Donc une « lecture » est en réalité un write-what-where, il vous suffit de choisir où atterrit la réponse. Lisez le jeton du processus SYSTEM depuis la mémoire physique, puis pointez la sortie directement vers votre propre champ de jeton EPROCESS. Le pilote écrit le jeton SYSTEM dans votre processus pour vous.
C'est tout l'exploit. Pas de corruption mémoire, pas de shellcode en mode noyau. SMEP, SMAP, KVAS, CET et CFG n'entrent jamais en jeu parce que rien ne s'exécute à CPL0 qui ne soit censé le faire. C'est uniquement de la donnée, et cela a fonctionné à chaque exécution. La seconde paire d'IOCTL (0xC3502584 lecture, 0xC3502580 écriture) est la classique. MSR arbitraire, sans liste blanche d'index. Lire IA32_LSTAR casse déjà KASLR à lui seul, et l'écrire détourne l'entrée des appels système. Cela nécessite du travail sur SMEP/SMAP donc je l'ai gardé comme chemin secondaire, mais même seul il est dangereux.
Compilez et exécutez depuis un compte utilisateur normal :
gcc -O2 -o poc.exe poc.c -lpsapi
poc.exe
Testé sur Windows 10 x64 22H2 (build 19045). Le pilote est livré avec Gigabyte App Center, donc sur beaucoup de cartes Gigabyte il est déjà chargé.
Je l'ai signalé à Gigabyte en juin 2026 et ils l'ont corrigé. Les versions plus récentes appliquent un SDDL sur le périphérique qui le verrouille aux administrateurs, et ajoutent une liste blanche sur l'écriture MSR. Le gdrv3 actuel n'est plus exploitable de cette manière.
