Сплайсинг ZwTerminateProcess

TermoSINteZ

Эксплоиты которые эскалацию привилегий до нулевого кпл выполняют оснеованы на обратных вызовах ядром пользовательского кода с ядерным контекстом. Это не вызывает проблем если код в пользовательском ап исполняется на нулевом IRQL и размаскированных прерываниях. В этом случае собственно диапазон память в котором находится исполняемый код не имеет значения и такие эксплоиты никогда не сбоят. Другое это когда пользовательский код вызывается ядром на завышенных IRQL или запрещённых прерываниях. Это часто сбоит изза подкачки и расширения стека, что требует применения спициальных средств(типо захвата региона созданием пользовательского потока в цикле юзающего страницы, в которых находится код, исполняемый на нулевом кпл и пр.).

Мне хорошо понятно почему такой способ признан Грейтом грубым - используется асм-вставка, причём даже я считаю её грязным хаком почемуто.., но это не значит что не будет работать или будет сбоить

 

Авторы сплоита плохо разбираются в ядре?! И кто ж хуже – Derek или Tavis?
...Уж как минимум между HEAP_PERFORM_CORRUPTION и HEAP_FREE_CHECKING_ENABLED они не запутаются, а PoC есть PoC и тотально надёжной реализации от подобных демонстрационных эксплоитов не требуется.

Вообще, это не так даже если писать в приватную память на однопроцессорных системах. Ибо между PageAccess и cli поток может быть остановлен на неопределённо долгое время. Да, вероятность того, что это произойдёт после PageAccess, но перед cli, помноженная на вероятность того, что страница будет выгружена, пока поток ждёт своего времени в очереди, даёт ничтожнейшую величину – но таки отличную от нуля величину.

 

Sol_Ksacap

 

Clerk
Логическое ударение на слове "ядро"? Если так, то это не отменяет того факта, что поток может быть прерван после доступа к памяти, до выполнения cli; Если не так, то испытываем затруднения в понимании, поясни.

TermoSINteZ
>Вообще то они не PoC предлогали.
Эм. Tavis обнаружил эпичнейший путь проэксплуатировать ошибку в обработчике #GP через использование VDM и сконструировал эксплоит, демонстрирующий уязвимость, который выложил в паблик спустя год после уведомления MS. "Демонстрационный" == "чтобы показать суть уязвимости", окей? Нигде не говорилось, что это боевое решение, работающее в 100% случаев. Фактически тот код – просто приложение к описанию, чтобы проще было понять сущность ошибки. Непонятно, зачем вообще могло понадобится компилировать этот код или запускать его.

 

Sol_Ksacap
Под ядром понимается собственно основной модуль(nt). Секции (.text и .data) не выгружаемые и не могут выгружаться, ибо функционал не распределён в памяти в зависимости от IRQL на котором юзается, да и нормально страницы по 2М.

 

Clerk
"Ядро" в качестве модуля, теперь видим. Первый шаг – 'ACCESS_PAGE' – дал решающий вес в пользу другого толкования. Но сейчас всё ясно, вопросов больше нет. Спасибо. (Хотя если б не использование больших страниц, мы бы не отстали

TermoSINteZ
>Но судя по диалогу - так вообще давайте будем верить всему что выкладывают и не компилировать.
Мы не отрицали, что компиляция и последующий трейсинг под отладчиком могут понадобиться. Но если стоит необходимость разобраться (а не самоутвердиться, за глаза обвинив профессионального исследователя в недостатке компетенции), то для статически легкоанализируемых случаев подобные действия ни к чему – таково наше мнение.

>Нафиг тогда выкладывать. Выложите куски псевдокода тогда и делов то.
Если это улучшит воспринимаемость и сохранит все сколько-нибудь существенные детали реализации, то в этом подходе есть определённые плюсы.

 

Sol_Ksacap

А можно теперь для ничтожного человечишки персонально? Зачем ACCESS_PAGE, если речь изначально шла о невыгружаемых страницах (что, кстати, согласно моему пониманию не очень согласуется с пунктом 1 поста 3)?

 

l_inc
Чтобы сепшен на нулевом иркл возник и не упало если что, на высоких сех не обработает. В случае если память выгружаемая вероятность оказаться преванным на Cli слишком мала, тоесть можно её пренебречь.

 

Clerk
Вообще я сначала хотел дождаться ответа Sol_Ksacap, но, учитывая, что он решил не отвечать, посчитав Ваш ответ исчерпывающим...

Откуда возьмётся исключение при доступе к валидной невыгружаемой странице памяти (разумеется, подразумевается, что она доступна на чтение)?

 

l_inc
Так ведь ACCESS_PAGE для выгружаемой памяти.

 

l_inc
Начинаем подозревать наличие проведения некого эксперимента с твоей стороны. Неет, Мы уже не можем быть разубеждены.

>Зачем ACCESS_PAGE, если речь изначально шла о невыгружаемых страницах?
Именно. Именно, что незачем – и это один из моментов, сбивавших Нас с толку. Однако, прочитав пост Clerk'а "Под ядром понимается собственно основной модуль[..]", Мы решили, что ACCESS_PAGE, присутствующая ранее – это лишняя деталь, возникший при построении фразы артефакт. Ведь если выкинуть 'ACCESS_PAGE', положить "ядро" == "модуль ядра", а также предположить, что используются большие страницы, то фраза "связка ACCESS_PAGE/CLEAR_IF/CLEAR_WP/ATOMIC_WRITE_PAGE абсолютно корректна и стабильна для ядра" становится валидной во всех случаях.

Да, последний и предпоследний посты Clerk'а делают всю цепочку выглядеть чередой непоследовательностей. Ну и пусть – уже бесполезно что-либо менять.

>не очень согласуется с пунктом 1 поста 3
Мм, этот пост Мы упустили из виду.


[Заметка]
IWRC, все большие страницы неподкачиваемы. При использовании же мелких страниц большая часть кода ядра подкачиваема – в т.ч. код функции NtTermnateProcess().

 

Насчет сброса WP тоже бывали частые проблемы при постоянной установке/снятии перехвата на двухядерных процах. Как стал использовать метод связанный с физ память, то стало работать гладко всё.

Код (Text):

1. PhysicalAddr = MmGetPhysicalAddress(Addr);
2. if (PhysicalAddr.QuadPart)
3. {
4.     VirtualAddr = MmMapIoSpace(PhysicalAddr, 4, 0);
5.     if (VirtualAddr)
6.     {
7.         *(ULONG*)VirtualAddr = NewVal; // установим свое значение
8.         MmUnmapIoSpace(VirtualAddr, 4);
9.     }
10. }

 

Sol_Ksacap

Что не понятно. Если страница есть в памяти, то к ней заранее обращаться не нужно, это если память не подкачиваемая.

 

Clerk

Так ведь не согласуется этот факт с высказыванием: "Связка ACCESS_PAGE/CLEAR_IF/CLEAR_WP/ATOMIC_WRITE_PAGE абсолютно корректна и стабильна для ядра". С учётом того, что, как выяснилось, под ядром понимаются невыгружаемые страницы основного модуля. В противном случае я согласен с Sol_Ksacap: связка нестабильна ввиду ненулевой вероятности выгрузки страницы до исполнения cli (даже если этой вероятностью можно спокойно пренебречь).
Ну да ладно. Сейчас это уже попытка пояснения моего непонимания, а не продолжение вопроса. Поэтому ответ уже не обязателен.
Sol_Ksacap

Ясно. Спасибо. Просто я с определённого момента следил за темой, и у меня возникали те же вопросы, что и у Вас. Пока Вы их задавали, я только ждал ответов (в том числе и потому, что недостаточно компетентен). Но начиная с фразы: "Но сейчас всё ясно, вопросов больше нет", — не удержался.

Мне просто понравились правила другого "затянувшегося эксперимента". И я их принял. Ничего особенного.

 

l_inc
Вот прицепились то.. Для не выгружаемых страниц аццесс не помешает, хотя и не нужен. Для выгруженых необходим. Просто когда я скопипастил свой текст с предыдущего поста возникла эта неопределённость. К сожалению посты я не могу править