moiz-2x/cve-2025-24990_pocProof of Concept CVE-2025-24990 (Agere-Systems-Treiber)
ltmdm64.sys). Dieser Treiber ist sehr alt und wird auf meinem Testrechner standardmäßig nicht geladen, daher werde ich ihn in einem BYOVD-Szenario ausnutzen. Interessanterweise existiert dieser Treiber laut meiner Recherche seit Windows 7 und hat mindestens einen Fehler. hier
Zu dieser Zeit hat MSRC keine Maßnahmen ergriffen 🤡
Einige IOCTLs in diesem Treiber verwenden METHOD_NEITHER, prüfen jedoch nicht, ob der vom Aufrufer bereitgestellte Adresspuffer aus dem Benutzermodus oder Kernelmodus stammt. Hier ist ein Beispiel-IOCTL-Code, den ich mit OSR dekodiert habe:
Das bedeutet, Sie können eine Kernel-Adresse an die DeviceIoControl-API übergeben und der Treiber verarbeitet sie normal.
Beachten Sie, dass Sie zuerst kASLR umgehen müssen, um die Kernel-Adresse zu leaken. Ich werde EnumDeviceDrivers verwenden (Unter Windows 24h2 benötigen Sie SeDebugPriv dafür).
Das Problem liegt im IOCTL 0x802b200f (ud_response). Auch hier validiert dieser IOCTL-Dispatch die Adresse, die ich aus dem Benutzermodus bereitstelle, nicht, aber ich werde sie später nutzen.
Das ud_response ruft ll_load_diagnostics auf, und ich erreiche den folgenden Code:
Zu Beginn ist die globale Variable eeprom nicht initialisiert, sodass sie NULL enthält. Hier ist ein einfacher Code, der dies auslöst.
Ich werde dies später nutzen.
Dieses IOCTL konvertiert einfach die Treiberversionszeichenfolge "8.36" in die Zahl 0x836 (ein DWORD) und schreibt sie an die vom Aufrufer bereitgestellte Adresse (dank METHOD_NEITHER). Technisch gesehen kann ich diese vier Bytes (36 08 00 00) an eine beliebige Kernel-Adresse schreiben. Ich werde dies nutzen, um die globalen Variablen des Treibers zu überschreiben und den Ausführungsfluss zu ändern.
Ich nenne dieses 0x802b2003 IOCTL_GET_VERSION
Beliebiges Null-1-Byte:
Zurück zum NULL-Dereferenzierungsfall: Ich verwende die VirtualAlloc-API, um eine feste Adresse (0x083600000000) zu allokieren. Dann verwende ich IOCTL_GET_VERSION, um an *(eeprom + 4) die oben beschriebenen vier Bytes zu schreiben. Wenn der Treiber später eeprom dereferenziert, liest er von der von mir allokierten Adresse.
Nach der Behebung der NULL-Dereferenzierung schreibt das IOCTL eine Zeichenfolge an die von mir aus dem Benutzermodus bereitgestellte Adresse, basierend auf der Puffergröße.
Dieser Code demonstriert einfach, was ich oben beschrieben habe: einen Puffer allokieren und mit 0xAA füllen, die NULL-Dereferenzierung beheben und dann den Treiber aufrufen. Beachten Sie, dass ich 11 Bytes allokiere, dem Treiber aber nur eine Puffergröße von 10 bereitstelle, um zu sehen, wie er sich verhält.
Er schreibt eine feste Bytefolge in meinen Puffer und nullt dann das letzte Byte (das 11.) aus, obwohl ich nur eine Größe von 10 bereitstelle. Es ersetzt das letzte 0xAA in meinem Puffer durch 0x00. Dies zeigt, dass der Treiber, wenn ich eine Größe von 0 bereitstelle, dennoch ein einzelnes 0x00-Byte an die Zieladresse schreibt.
Beliebige Dekrementierung
Jetzt habe ich das Null- und das beliebige Schreiben mit festen 4 Bytes, lassen Sie uns eine weitere Primitive erstellen.
Dieses IOCTL setzt das globale LtMsgEvent auf meinen Benutzerpuffer, prüft dann, ob WDM null ist, und setzt es wieder auf null.
Dann ruft es in 0x802b2207 die ObfReferenceObject-API auf.
Im Ausgangszustand ist WDM null, aber mit Hilfe von IOCTL_GET_VERSION kann ich WDM auf 0x36 setzen (es ist nur 1 Byte groß) und LtMsgEvent ist immer noch mein Puffer. Dann nullte ich WDM aus und rufe 0x802b2207 auf. Schließlich erreiche ich ObfReferenceObject. Ich nenne diese beiden IOCTLs IOCTL_SET_LtMsgEvent und IOCTL_DEREF_LtMsgEvent.
Die Exploit-Technik mit ObfReferenceObject ändert den PreviousMode unseres KTHREAD von UserMode zu KernelMode. Sie können darüber hier lesen. Windows hat diesen Exploit jedoch behoben, sodass wir ihn nicht verwenden können.
Aber die Primitive in ObfReferenceObject existiert immer noch. Die API subtrahiert 0x30 von der von uns bereitgestellten Adresse, interpretiert das Ergebnis als 8-Byte-Ganzzahl und subtrahiert dann 1.
*(signed long long)(LtMsgEvent-0x30) -= 1
Das Problem ist jedoch, dass geprüft wird, ob der nächste Wert 0 ist oder ob der aktuelle Wert < 1 ist (interpretiert als 8-Byte-Ganzzahl mit Vorzeichen). Wenn eine der Bedingungen zutrifft, springt es zu KeBugCheckEx und stürzt das System ab.
Beliebiges Schreiben
Mit der beliebigen Dekrementierung in der Hand muss ich einen anderen Ort finden, um das Byte 0xFF zu schreiben und es dann auf das gewünschte Byte zu dekrementieren. Ich habe dieses IOCTL 0x802b2243 gefunden:
Wir konzentrieren uns auf den flip-Zweig. pbVar5 ist die Adresse, die ich aus dem Benutzermodus bereitstelle, und kann eine beliebige Zieladresse sein, die ich wähle. Ich schreibe das Byte 0x0C an DAT_TARGET_EX (mit Hilfe von IOCTL_GET_VERSION und der beliebigen Dekrementierungs-Primitive) und nullte auch 1 Byte an der Zieladresse aus. Der erste Aufruf dieses IOCTLs setzt 0xC0 an der Zieladresse, das dann auf 0xBF dekrementiert wird. Ein zweiter Aufruf setzt 0xFF an der Zieladresse (0xBF | 0xC0 = 0xFF). Sobald das Ziel 0xFF enthält, dekrementiere ich es einfach auf den gewünschten Wert.
Ich schreibe ein Byte nach dem anderen und achte auf das KeBugCheckEx in ObfReferenceObject.
Beliebiges Lesen
Für die Lese-Primitive verwende ich die hier beschriebene Technik (@carrot_c4k3). Ich überschreibe einfach das UNICODE_STRING-Objekt im Kernel (ExpManufacturingInformation) und rufe dann NtQuerySystemInformation auf. Da ObfReferenceObject KeBugCheckEx aufruft, nullte ich 8 Bytes neben ExpManufacturingInformation aus.
Das war's, jetzt haben wir beliebiges R/W. Wir können diese Primitive für viele Dinge nutzen. Der Treiber wird standardmäßig nicht geladen, daher werde ich ihn in einem BYOVD-Szenario ausnutzen und die PPL eines Prozesses setzen.
Der Exploit, den ich oben beschrieben habe, funktioniert auf allen Windows-Versionen, ist aber aufgrund des KeBugCheckEx instabil. Unter Windows 11 22h2+ gibt es jedoch eine Technik namens ioring. Diese Technik überschreibt einfach ioring->Buffer mit einer kontrollierbaren Adresse. Konkret können wir ioring->Buffer und seine Größe mit 0x083600000000 bzw. 0x836 überschreiben (mit IOCTL_GET_VERSION). Mit dieser Technik führe ich nur 2 Schreibvorgänge durch und nutze dann die R/W-Primitive sehr stabil. Beachten Sie, dass dieser Ansatz das Leaken der Kernel-Adresse erfordert.
Windows lädt den Treiber im Standardzustand nicht. Sie müssen ihn also manuell laden. Die Datei ltmdm64.sys befindet sich unter C:\Windows\System32\DriverStore\...\ltmdm64.sys. Führen Sie diesen Befehl als Administrator aus und starten Sie den Exploit:
sc create ltmdm64_srv binPath="C:\Windows\System32\DriverStore...\ltmdm64.sys" type=kernel && sc start ltmdm64_srv
Der Exploit verwendet die ioring-Technik, um die PPL von lsass.exe zu deaktivieren, und meine reine Daten-Technik, um die PPL von notepad.exe zu setzen (unter Win 11 24h2 muss SeDebugPriv aktiviert sein).
https://github.com/user-attachments/assets/05a35b38-d26c-484f-9fb7-137f8fe8c079
Ich habe diesen Fehler an ZDI gemeldet. Aber es scheint, dass er mit der Einreichung von Fabian Mosch und Jordan Jay bei MSRC dupliziert wurde. Dieser PoC zeigt also nur den Fehler und würdigt ihre Arbeit. Fast meine erste CVE 😍