mein-0/mercilessamdProof-of-Concept, das die MSR-Lese-/Schreib-IOCTLs von AMD AmdTools64.sys ausnutzt, um IA32_LSTAR zu überschreiben, SMEP zu umgehen und unter Windows 10 x64 von Administrator zu SYSTEM zu eskalieren.
hi Hacker.
AmdTools64.sys ist der signierte Special-Tools-Treiber, der mit AMD uProf ausgeliefert wird. Kein UAC-Bypass, keine Standardbenutzer-Grenze. Sobald man das Handle hat, gibt es keine Whitelist für den MSR-Index, sodass man jeden beliebigen MSR lesen und schreiben kann.
Die Leseseite bricht KASLR bereits von selbst. Liest man IA32_LSTAR (0xC0000082), liefert der Treiber einem ntoskrnl!KiSystemCall64 gratis. Die Schreibseite ist das eigentliche Problem. IA32_LSTAR ist die Adresse, zu der die CPU bei jedem Syscall springt, und der Treiber erlaubt einem normalen Benutzer, sie zu überschreiben. Richtet man sie auf Code, den man kontrolliert, führt der nächste Syscall den eigenen Code auf CPL0 aus. SMEP ist das Einzige, was im Weg steht, also liest der Exploit zuerst IA32_LSTAR, um ntoskrnl zu finden, parst das Import-Verzeichnis von der Festplatte, findet ein paar Gadgets, um SMEP mit mov cr4, rax zu deaktivieren, führt einen kleinen Shellcode aus, der das SYSTEM-Token in den aktuellen Prozess kopiert, und stellt IA32_LSTAR beim Verlassen wieder her, damit die Maschine weiterläuft.
Es gibt zwei IOCTLs, und das ist die ganze Geschichte. 0xFFF02804 liest einen MSR und 0xFFF02808 schreibt einen, beide mit einem 20-Byte-Puffer und ohne Indexvalidierung. Der Dispatcher prüft nur die Pufferlängen. Es gibt außerdem einen physischen Speicher-Lese-/Schreibzugriff und eine physische Benutzermodus-Map (0xFFF0281C, 0xFFF02820, 0xFFF028A4), aber der Map-Pfad kann bei beliebigem RAM PFN_LIST_CORRUPT auslösen, daher wird hier der MSR-Pfad verwendet.
Ich habe das auf Windows 10 x64 22H2 (Build 19045.6456) mit AMD uProf 5.3.521.0 getestet. Der Treiber hat Version 1.7.16.218. Keine Race-Condition und kein Heap-Grooming, es funktionierte bei jedem Durchlauf. Der Treiber wird mit uProf ausgeliefert und ist auf vielen AMD-Maschinen installiert, ist also bereits für einen geladen. Der Screenshot ist die Win10-Maschine: whoami ist vorher subhan\windows10, nachher nt authority\system.
Auf Windows 11 26300 konnte ich den Treiber installieren und IA32_LSTAR lesen, aber das wrmsr auf LSTAR schlägt fehl, wenn Memory Integrity aktiviert ist, da VBS/HVCI es abfängt. Das bekannte Win11-EPROCESS-Layout ist UniqueProcessId 0x1D0, ActiveProcessLinks 0x1D8, Token 0x248, ImageFileName 0x338, abgeglichen mit PsGetProcessId, PsReferenceProcessToken und PsGetProcessImageFileName in diesem Build.
Der Wert liegt im signierten Treiber und dem Kernel-Primitiv: Ein Administrator kann den AMD-Treiber laden und Ring-0-Codeausführung erlangen. Die LSTAR-zu-SYSTEM-Kette hier ist der Exploit-Teil, keine neue Treiberentdeckung.
Ich habe es am 2026-08-17 an AMD PSIRT gemeldet. Sie haben jedoch alles in ihrer Macht Stehende getan, um diese Lücke nicht anerkennen zu müssen; sie haben mich sogar bei Gmail blockiert, sodass ich ihnen keine E-Mails mehr von meiner eigenen Adresse senden konnte. Das ist erst der Anfang; künftig werde ich meine Erkenntnisse zu AMD-Produkten nicht mehr direkt oder über ihre anderen Kanäle mit ihnen teilen. Ich werde weiterhin alles genau hier teilen. Bleibt dran und hackt weiter!
