mein-0/knockgigaProof-of-Concept zur lokalen Rechteausweitung, das die IOCTLs von Gigabyte gdrv3.sys ausnutzt, um das SYSTEM-Token über einen ungeprüften physischen Speicherzugriff in einen Benutzerprozess zu schreiben.
hi Hacker.
gdrv3.sys ist der signierte Kernel-Treiber, der mit Gigabyte App Center und EasyTune ausgeliefert wird. Er erstellt \.\GIOV3 ohne Sicherheitsdeskriptor, sodass jeder lokale Benutzer ihn öffnen kann – kein Admin, kein UAC. Zwei seiner IOCTLs sind die ganze Geschichte.
Der erste (0xC3502019) gibt vor, physischen Speicher zu lesen. Man übergibt ihm eine physische Adresse, eine Länge und einen Ausgabezeiger, und er kopiert die Bytes dorthin. Der Ausgabezeiger ist das Problem: Der Treiber prüft nie, ob er im Benutzerbereich liegt. Kein ProbeForWrite, keine Grenzprüfung, nichts. Ein „Lesevorgang" ist also in Wahrheit ein Write-what-where – man wählt nur, wo das Ergebnis landet. Lies das SYSTEM-Prozesstoken aus dem physischen Speicher und richte den Ausgabezeiger direkt auf dein eigenes EPROCESS-Token-Feld. Der Treiber schreibt das SYSTEM-Token für dich in deinen Prozess.
Das ist der gesamte Exploit. Keine Speicherbeschädigung, kein Shellcode im Kernel-Modus. SMEP, SMAP, KVAS, CET und CFG kommen nie ins Spiel, weil nichts auf CPL0 läuft, was dort nicht laufen soll. Es sind reine Daten, und es funktionierte bei jedem Durchlauf. Das zweite IOCTL-Paar (0xC3502584 lesen, 0xC3502580 schreiben) ist das klassische. Beliebiges MSR, keine Index-Whitelist. Das Lesen von IA32_LSTAR bricht bereits für sich genommen KASLR, und das Schreiben kapert den Syscall-Einstiegspunkt. Es erfordert SMEP/SMAP-Arbeit, daher habe ich es als sekundären Pfad beibehalten, aber selbst allein ist es übel.
Kompilieren und ausführen aus einem normalen Benutzerkonto:
gcc -O2 -o poc.exe poc.c -lpsapi
poc.exe
Getestet auf Windows 10 x64 22H2 (Build 19045). Der Treiber wird mit Gigabyte App Center ausgeliefert, ist also auf vielen Gigabyte-Mainboards bereits geladen.
Ich habe es im Juni 2026 an Gigabyte gemeldet, und sie haben es behoben. Die neueren Builds versehen das Gerät mit einer SDDL, die es auf Administratoren beschränkt, und fügen eine Whitelist für das MSR-Schreiben hinzu. Das aktuelle gdrv3 ist auf diese Weise nicht mehr ausnutzbar.
