Обзор эксплойтов

Крис Касперски

Хакер, номер #095, стр. 095-060-4

Что изменилось в висте? Системные библиотеки теперь грузятся по одному из 256-ти возможных базовых адресов, выбираемому случайным образом. В заголовке исполняемых файлов появился специальный бит, указывающий, должен ли он загружаться по фиксированному или наугад взятому адресу. То же самое относится к несистемным динамическим библиотекам. Это значит, что в настоящий момент реально радномизируются только системные библиотеки и приложения, входящие в комплект штатной поставки висты. Все ранее написанные приложения грузятся по одному и тому же адресу и будут грузиться по нему еще долго, поскольку сторонние разработчики крайне прохладно относятся к новой инициативе Microsoft. И даже когда появятся линкеры, поддерживающие флаг рандомизации, вовсе не факт, что каждый поспешит им воспользоваться. Причина этому в том, что загрузка по произвольному адресу требует наличия таблицы перемещаемых элементов, увеличивает потребности в оперативной памяти (особенно при запуске нескольких копий приложения) и облегчает взлом, поскольку существующие упаковщики/протекторы не поддерживают рандомизацию и распаковывают файл по фиксированным адресам. Отсюда следует, что часть адресного пространства уязвимого приложения, относящаяся к исполняемому файлу и его личным динамическим библиотекам, по-прежнему остается предсказуемой. А это позволяет атакующему свободно передавать управление на shell-код через jmp esp, а также вызывать любые функции, содержащиеся в уязвимом приложениии или импортируемые им и в таблице импорта конкретно взятого приложения ее вполне может и не быть. На самом деле, ситуация практически никак не изменилась. Вероятность успешной атаки (с учетом кучи версий Windows) и раньше не составляла 100%, теперь же она сократилась приблизительно в 256 раз. И это они еще называют надежной защитой! Ну-ну... Тот, кто очень хочет, своего добьется. Если хакер будет настойчиво долбиться, рано или поздно он угадает базовый адрес KERNEL32.DLL, содержащей все необходимые ему функции, и тогда жертва падает. То есть как раз наоборот - тогда произойдет захват управления удаленной машиной, а во всех остальных случаях — ее падение. Администратор запарится поднимать сервер (рабочую станцию), не понимая, то ли это его атакуют, то ли что-то конкретно глючит (например, сбоит память). Правда, заподозрив атаку, он сможет быстренько скачать все заплатки (при условии, что они есть), заткнув дыры. А при настойчивой долбежке компьютер будет падать так часто, что ничего скачать не удастся! Но все-таки, падения — это нехорошо. Зачем привлекать излишнее внимание? Чтобы подавить сообщения о критических ошибках, необходимо перезаписать указатель на текущий обработчик структурных исключений, с которым связана еще одна оборонная инициатива Microsoft — в висте он перемещен из легко затираемого стека в секцию .pdata, доступную только для чтения. Все это относится только к статическим обработчикам структурных исключений, адрес которых известен еще на стадии компиляции. Это справедливо для простых Си-программ, но в Си++ достаточно большое количество обработчиков устанавливаются динамически. К тому же установкой обработчиков ведает компилятор, а все существующие компиляторы размешают указатели на обработчики в стеке! Так что появление висты само по себе ничего не меняет. Как минимум необходимо дождаться появления обновленных версий компиляторов, а до этого можно смело перезаписывать и переназначать обработчики структурных исключений на свои собственные. Правда, начиная с Server 2003, система выполняет дополнительную проверку, препятствующую размещению кода обработчика в стеке. Но… можно подсунуть адрес одного из обработчиков уязвимого приложения, который бы не завершал работу приложения и не выдавал бы никаких сообщений на экран, а тем или иным образом обработав исключение, продолжал бы работу в обычном режиме. В большинстве случаев для этого достаточно прыгнуть сразу в середину обработчика поближе к API-функции Continue, и можно смело долбить переполняющийся буфер, перебирая все возможные варианты один за другим.