canomer/cve-2025-54110-kernel-eop-pocДата проекта : Окт 2025 / реализация PoC для CVE-2025-54110 уязвимости целочисленного переполнения на уровне ядра в Windows системном вызове `NtQueryDirectoryObject`.
Реализация PoC для CVE-2025-54110 — уязвимости переполнения целого числа на уровне ядра в системном вызове Windows NtQueryDirectoryObject.
CVE: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-54110
Этот репозиторий содержит Crash-Only PoC для уязвимости CVE-2025-54110 повышения привилегий ядра, разработанный исключительно для исследования безопасности, реверс-инжиниринга и исследований разработки эксплойтов. Этот код предназначен для демонстрации методов исследования уязвимостей, включая:
Этот PoC НЕ обеспечивает повышение привилегий или надежный BSOD. Он предназначен для безопасного вызова нарушений доступа, которые перехватываются защитой ядра Windows.
Дата публикации: Сентябрь 2025 (Windows Tuesday Security Patch)
| Свойство | Значение |
|---|---|
| CWE | CWE-190: Переполнение целого числа или циклический переход |
| Оценка CVSS 3.1 | 8.8 (Высокий) / 7.7 (Временная) |
| Вектор атаки | 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 |
| Вектор атаки | Локальный |
| Сложность атаки | Низкая |
| Необходимые привилегии | Низкие |
| Взаимодействие пользователя | Нет |
| Область действия | Изменена |
| Конфиденциальность | Высокая |
| Целостность | Высокая |
| Доступность | Высокая |
| Зрелость эксплойта | Не доказана |
Уязвимость переполнения целого числа в ядре Windows позволяет аутентифицированному злоумышленнику потенциально повысить привилегии локально. Согласно рекомендациям Microsoft:
"Злоумышленник может воспользоваться этой уязвимостью, отправив специально созданные данные из изолированного процесса в пользовательском режиме, чтобы вызвать переполнение целого числа, что приведет к переполнению буфера в ядре и позволит повысить привилегии или выйти из изолированной среды."
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. Проанализированные файлы
Первоначальный анализ был сосредоточен на двух основных компонентах ядра:
#### win32k.sys (-)
- **Результат:** Значительных изменений не обнаружено
- **Диапазон оценок:** 0.97-1.0 (высокое сходство)
- **Заключение:** Не является уязвимым компонентом для CVE-2025-54110
#### ntoskrnl.exe (+)
- **Результат:** Множество функций со значительными изменениями
- **Диапазон оценок:** Функции с оценками ≤0.951
- **Различия в длине:** Обнаружены различия в длине байтов между исходным и целевым файлами
- **Всего экспортировано элементов:** 2,036 функций для анализа
### 3. Результаты отслеживания версий Ghidra
Пример выявленных изменений в `ntoskrnl.exe`:
| Оценка | Достоверность | Длина источника | Длина назначения | Исходная функция | Целевая функция |
|-------|---------------|-----------------|-----------------|------------------|-----------------|
| 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
### Технический подход
PoC (`precise_overflow_bsod.c`) пытается вызвать уязвимость целочисленного переполнения через:
1. **Точное вычисление порога:** `0xfffffdbc` (получено из base=0x20, name=0x200)
2. **API NtQueryDirectoryObject:** Целевая функция для запуска переполнения
3. **Многофазная стратегия атаки:**
- Фаза 1: Попытки точного целочисленного переполнения
- Фаза 2: Нацеливание на память ядра
- Фаза 3: Многопоточная эксплуатация
### Структура кода```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
---
## Почему PoC не приводит к сбою системы
### Фактические результаты
PoC последовательно возвращает `STATUS_ACCESS_VIOLATION (0xC0000005)` без появления синего экрана смерти (BSOD). Это **сделано намеренно** и демонстрирует несколько критических механизмов безопасности ядра Windows:
### 1. Структурированная обработка исключений (SEH)```
User-Mode Input → NtQueryDirectoryObject
↓
ProbeForRead/Write
↓
__try { ... }
↓
Access Violation Detected
↓
__except { ... }
↓
Return STATUS_ACCESS_VIOLATION
Почему это работает:
Современная функция процессора, которая предотвращает доступ режима ядра (Ring 0) к памяти пользовательского режима (Ring 3) без явного разрешения:``` 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
**Влияние на PoC:**
- Даже если происходит переполнение, прямой доступ к памяти из ядра в пользовательское пространство блокируется
- Предотвращает эксплуатацию уязвимостей, связанных с разыменованием указателей
### 3. KASLR (Рандомизация макета адресного пространства ядра)```
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
Почему BSOD не происходит: