Если задаться целью, то можно сформулировать основные постулаты защиты ядра от юзермодного кода (UC) примерно так:
- UC не должен иметь доступа к адресному пространству режима ядра;
- UC не должен иметь доступа к дескрипторам режима ядра(kernel mode handles);
- UC обязан проходить проверку доступа (access check) при работе с объектами системы;
К драйверам режима ядра такие ограничения, естественно, не применимы. Исходя из этих постулатов, возникает вполне закономерный вопрос - каким же образом NT разграничивает доступ к системным сервисам для user mode и kernel mode вызовов?
Дело в том, что в NT с каждым потоком ассоциировано некоторое поле, указывающее системному сервису, в каком режиме находился вызывающий тред до вызова функции ядра - поле это называется Previous Mode, и находится в кернельном TEB'е (Thread Environment Block). Тип этого поля представляет собой enum, описанный в DDK следующим образом:
typedef enum _MODE { |
PsGetCurrentThread()->KernelTEB->PreviousMode;
Для того, чтобы лучше понять детали реализации этого решения Microsoft, имеет смысл воспользоваться следующей схемой:

- вызов CreateFile из пользовательского приложения (MyApplication.EXE).
Который раскрывается в цепочку вызовов:
ntdll.NtCreateFile -> ntoskrnl.KiFastCallEntry -> ntoskrnl.NtCreateFile - вызов ZwCreateFile из драйвера режима ядра (MyDriver.SYS), проходящий другой сложный и интересный путь:
ntoskrnl.ZwCreateFile -> ntoskrnl.KiSystemService -> ntoskrnl.KiFastCallEntry -> ntoskrnl.NtCreateFile
А функция KiSystemService и есть та самая дивная функция, которая устанавливает PreviousMode равным KernelMode, указывая на то, что вызывающий компонент имеет право использовать все свои драйверные полномочия.
Таким образом, алгоритм ZwCreateFile можно схематично представить так:
1. SetPreviousMode(KernelMode);Такая себе абстракция "четыре-в-одном".
2. GetCallAddressValueFromSST (that corresponding NtCreateFile in normal way);
3. Call it;
4. SetPreviousMode(OldMode);
А что, если нам бы захотелось вызвать NtCreateFile напрямую, без диспетчеризации по SST? Такое желание может возникнуть, к примеру, если мы вспомним о существовании целого класса руткитов, основанных на подмене записей SST таблицы. Чтобы противостоять этому классу руткитов, достаточно написать свою функцию следующего вида:
1. SetPreviousMode(KernelMode);Однако проблема состоит в том, что функции SetPreviousMode попросту не существует.
2. Call NtCreateFile;
3. SetPreviousMode(OldMode);
Тем более приятно написать свою!
Поскольку вбивать смещения для всех сервиспаков по меньшей мере скучно, попытаемся программно проанализировать код. К примеру, вот так выглядят популярные реализации GetPreviousMode:
И этой информации достаточно, чтобы написать свою функцию CreateSetPreviousModeStub, задачей которой будет анализ имеющейся функции KeGetPreviousMode и создание новой SetPreviousMode:
2K
nt!KeGetPreviousMode:
80465320 a1 24f1dfff mov eax,[ffdff124]
80465325 0f b6 80 34010000 movzx eax,byte ptr [eax+0x134]
8046532c c3 ret
XP
nt!KeGetPreviousMode:
804daae3 a1 24f1dfff mov eax,[ffdff124]
804daae8 0f b6 80 40010000 movzx eax,byte ptr [eax+0x140]
804daaef c3 ret
2003
nt!KeGetPreviousMode:
8083a3a7 64 a1 24010000 mov eax,fs:[00000124]
8083a3ad 0f b6 80 d7000000 movzx eax,byte ptr [eax+0xd7]
8083a3b4 c3 ret
|
_Winnie C++ Colorizer |
Итого - вызываем CreateSetPreviousModeStub и наслаждаемся.
Именно в такой последовательности.
Поддержка Vista
|
No comments:
Post a Comment