canomer/cve-2025-54110-kernel-eop-pocProjektdatum: Okt. 2025 / PoC-Implementierung für CVE-2025-54110, eine Kernel-Level Integer Overflow Schwachstelle im Windows `NtQueryDirectoryObject` Systemaufruf.
PoC-Implementierung für CVE-2025-54110, eine Kernel-Level Integer-Overflow-Schwachstelle im Windows-Systemaufruf NtQueryDirectoryObject.
CVE: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-54110
Dieses Repository enthält einen Crash-Only PoC für die Kernel-EoP-Schwachstelle CVE-2025-54110, der ausschließlich für Sicherheitsforschung, Reverse Engineering und Exploit-Entwicklungsforschung entwickelt wurde. Dieser Code soll Techniken der Schwachstellenforschung demonstrieren, darunter:
Dieser PoC erreicht KEINE Privilegienausweitung oder zuverlässigen BSOD. Er soll sicher Zugriffsverletzungen auslösen, die von den Windows-Kernel-Schutzmechanismen abgefangen werden.
Veröffentlichungsdatum: September 2025 (Windows Tuesday Security Patch)
| Eigenschaft | Wert |
|---|---|
| CWE | CWE-190: Integer-Overflow oder -Wraparound |
| CVSS 3.1 Score | 8.8 (Hoch) / 7.7 (Zeitlich) |
| Vector String | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C |
| Attack Vector | Lokal |
| Attack Complexity | Niedrig |
| Privileges Required | Niedrig |
| User Interaction | Keine |
| Scope | Geändert |
| Confidentiality | Hoch |
| Integrity | Hoch |
| Availability | Hoch |
| Exploit Maturity | Nicht nachgewiesen |
Eine Integer-Overflow-Schwachstelle im Windows-Kernel ermöglicht es einem authentifizierten Angreifer, lokal möglicherweise Privilegien zu erhöhen. Laut Microsofts Sicherheitshinweis:
"Ein Angreifer könnte diese Schwachstelle ausnutzen, indem er speziell präparierte Eingaben von einem sandboxierten Benutzermodusprozess sendet, um einen Integer-Overflow auszulösen, was zu einem Pufferüberlauf im Kernel führt und eine Privilegienausweitung oder Sandbox-Escape ermöglicht."
Windows Update Files from Aug 2025 & Sep 2025 (KB.msu) ↓ Extract CAB Files ↓ Calculate SHA-256 Hashes (August vs September) ↓ Identify Changed Files ↓ Ghidra Version Tracking Analysis ↓ Setting Symbol Servers to Clarify Function Names ↓ Function-Level Diff Comparison
### 2. Analysierte Dateien
Die erste Analyse konzentrierte sich auf zwei primäre Kernel-Komponenten:
#### win32k.sys (-)
- **Ergebnis:** Keine signifikanten Änderungen festgestellt
- **Bewertungsbereich:** 0.97-1.0 (hohe Ähnlichkeit)
- **Fazit:** Nicht die anfällige Komponente für CVE-2025-54110
#### ntoskrnl.exe (+)
- **Ergebnis:** Mehrere Funktionen mit signifikanten Änderungen
- **Bewertungsbereich:** Funktionen mit Bewertungen ≤0.951
- **Längenunterschiede:** Unterschiede in der Bytelänge zwischen Quelle und Ziel festgestellt
- **Exportierte Elemente insgesamt:** 2,036 Funktionen zur Analyse
### 3. Ergebnisse der Ghidra-Versionsverfolgung
Beispiel identifizierter Änderungen in `ntoskrnl.exe`:
| Bewertung | Konfidenz | Quelllänge | Ziellänge | Quellfunktion | Zielfunktion |
|-------|------------|---------------|-------------|-----------------|---------------|
| 0.951 | 2.618 | 1023 | 365 | FUN_1403146d0 | FUN_1403a4ea0 |
| 0.950 | 2.285 | 113 | 203 | FUN_140680810 | FUN_1406d952c |
| 0.950 | 3.137 | 782 | 1050 | FUN_14032106c | FUN_140303a38 |
| 0.951 | 2.675 | 141 | 171 | FUN_140407bd0 | FUN_140a172a0 |
| 0.951 | 2.660 | 346 | 150 | FUN_140610e60 | FUN_1406115d4 |
---
## PoC-Erklärung
### Technischer Ansatz
Das PoC (`precise_overflow_bsod.c`) versucht, die Integer-Überlauf-Schwachstelle auszulösen durch:
1. **Präzise Schwellwertberechnung:** `0xfffffdbc` (abgeleitet von base=0x20, name=0x200)
2. **NtQueryDirectoryObject API:** Zielfunktion zum Auslösen des Überlaufs
3. **Mehrphasige Angriffsstrategie:**
- Phase 1: Präzise Integer-Überlaufversuche
- Phase 2: Kernel-Speicher anvisieren
- Phase 3: Multithread-Ausnutzung
### Code-Struktur```c
// Key threshold values calculated for overflow
ULONG precise_thresholds[] = {
0xfffffdbc, // Precise threshold - base=0x20, name=0x200
0xfffffdbb, // Threshold - 1
0xfffffdbd, // Threshold + 1
0xfffffdba, // Threshold - 2
0xfffffdbe, // Threshold + 2
};
// Buffer configurations to test edge cases
PVOID buffer_types[] = {
VirtualAlloc(NULL, 0x1000, MEM_COMMIT, PAGE_READWRITE), // Normal buffer
VirtualAlloc(NULL, 0x10, MEM_COMMIT, PAGE_READWRITE), // Small buffer
NULL, // NULL pointer
(PVOID)0x4141414141414141, // Invalid pointer
(PVOID)0x0000000000000000, // Zero address
};
NtQueryDirectoryObject() Parameters: ├── DirectoryHandle: \BaseNamedObjects, \KernelObjects, etc. ├── Buffer: Various pointer configurations ├── BufferLength: Calculated overflow thresholds (0xfffffdbc variants) ├── ReturnSingleEntry: TRUE/FALSE variations ├── RestartScan: TRUE/FALSE variations └── Context: Controlled iteration state
---
## Warum der PoC das System nicht zum Absturz bringt
### Tatsächliche Ergebnisse
Der PoC gibt konsistent `STATUS_ACCESS_VIOLATION (0xC0000005)` zurück, ohne einen Blue Screen of Death (BSOD) zu verursachen. Dies ist **absichtlich so** und demonstriert mehrere kritische Sicherheitsmechanismen des Windows-Kernels:
### 1. Strukturierte Ausnahmebehandlung (SEH)```
User-Mode Input → NtQueryDirectoryObject
↓
ProbeForRead/Write
↓
__try { ... }
↓
Access Violation Detected
↓
__except { ... }
↓
Return STATUS_ACCESS_VIOLATION
Warum es funktioniert:
Moderne CPU-Funktion, die verhindert, dass der Kernel-Modus (Ring 0) ohne explizite Autorisierung auf Benutzermodus-Speicher (Ring 3) zugreift:``` Kernel attempts to access user pointer ↓ SMAP checks permission (STAC/CLAC instructions) ↓ Unauthorized access detected ↓ CPU generates #PF (Page Fault) ↓ Caught by kernel exception handler
**Auswirkungen auf den PoC:**
- Selbst wenn ein Überlauf auftritt, ist der direkte Speicherzugriff vom Kernel zum Benutzer blockiert
- Verhindert die Ausnutzung von Schwachstellen durch Zeiger-Dereferenzierung
### 3. KASLR (Randomisierung der Kernel-Adressraum-Layout)```
Boot Time: Kernel Base = Random Address
↓
Hardcoded PoC address (0xfffffdbc)
↓
Does NOT match actual kernel structures
↓
Write to non-critical memory OR caught by SEH
Warum kein BSOD auftritt: