ms09-025, win2k code execution

Одна из 4-х запатченных уязвимостей в бюллетени ms09-025, переполнения стека, но не простое.
POC:

Код (Text):

1. #include <windows.h>
2. int main()
3. {
4.  WCHAR c[1000] = {0};
5.  memset(c, ‘c’, 1000);
6.  SystemParametersInfo(SPI_SETDESKWALLPAPER, 0, (PVOID)c, 0);
7.  
8.  WCHAR b[1000] = {0};
9.  SystemParametersInfo(SPI_GETDESKWALLPAPER, 1000, (PVOID)b, 0);
10.  return 0;
11. }

На XP и 2k3 присутствует /GS, то есть только BSOD.
На win2k /GS отсутсвует, легко попадаем на наш ядерный шелкодес.
Сложность заключается в том, что затирается адрес возврата не в ф-ии где происходит переполнение(xxxSystemParameterInfo), а в родительской ф-ии.
Иерархия вызовов:
KiSystemService->NtUserSystemParameterInfo->xxxSystemParameterInfo(переполнение на wcscpy)
при выходе из xxxSystemParameterInfoмы контролируем значение на инстукции call [ebp+N].
Но, адрес возврата в KiSystemService затёрт, что лучше применить в shellcode чтобы не уронить систему(стартануть другой поток, а поток у которого затёрт стек заморозить):
1.jmp 0x0 - GUI виснет
2.KeDelayExecutionThread?
3.Какие либо другие варианты???

 

Последний стековый фрейм определяет трап-фрейм, там юзермодный контекст, можно восстановить, если вопрос в этом.

 

Clerk
Вы предлагаете проэмулировать работу KiSystemServiceExit?

 

Нет. Есть одна особенность, которая открывает широкие возможности. Это то, что подобные функции выполняются на низком IRQL, что позволяет обработать исключение посредством отладочного нотификатора.
1. KTRAP_FRAME формируется при любом входе в ядро, также в аппаратные прерывания и исключения без смены CPL.
2. Цепочка стековых фреймов позволяет определить адрес процедуры в которой произошло исключение.
3. Адрес регистрового фрейма фиксирован в обьекте описывающем поток, определён в TSS и лежит в стеке выше последнего стекового фрейма.
4. Известен код, который вызывает исключения.
5. Возможно полноценное использование трассировки.
В совокупности это позволяет обаботать всё что угодно, даже если некоторая часть стека была затёрта.
Касательно кода формирующего регистровые фреймы(KiTrapXX etc.) и загружающего их в процессор(KiServiceExit etc.) на данный момент альтернатива всякой эмуляции - морфинг(перемещение обработчика в другую область памяти).

 

белка?

Ev0lwaves

Ну дык вполне себе вариант в чем проблема?

Другой вариант восстановить этот адрес возврата самостоятельно. Получить базу ядра плюс rva куда должен быть возврат в зависимости от версии ОС например, м?

Еще вариант пропарсить ktrap_frame и сделать iretd/sysexit ручками

 

Зачем, если есть Kei386EoiHelper().

 

Exploit написан, всем спасибо!
jmp 0x0 вполне подходит, главное не находится в критической секции, иначе GUI виснет.