последствия ядерной войны

КРИС КАСПЕРСКИ АКА МЫЩЪХ

Спецвыпуск: Хакер, номер #072, стр. 072-062-6

С большим опозданием в Висте появилась поддержка рандомизации адресного пространства Address Space Layout Randomization (ASLR). По умолчанию все системные библиотеки теперь загружаются по одному из 256 возможных адресов, а в заголовке исполняемых файлов появился специальный бит, указывающий, должен ли он загружаться по случайному адресу или нет.

Подробности о реализации ASLR от Microsoft можно почерпнуть из блога http://blogs.msdn.com/michael_howard/archive/2006/05/26/608315.aspx. Там даже приводится конкретный пример расположения системных библиотек ноутбука автора до и после перезагрузки:

Базовые адреса некоторых системных библиотек в Висте

wsock32.dll (0x73ad0000)

winhttp.dll (0x74020000)

user32.dll (0x779b0000)

kernel32.dll (0x77c10000)

gdi32.dll (0x77a50000)

Базовые адреса тех же самых библиотек после перезагрузки системы

wsock32.dll (0x73200000)

winhttp.dll (0x73760000)

user32.dll (0x770f0000)

kernel32.dll (0x77350000)

gdi32.dll (0x77190000)

Насколько этот трюк усложняет атаку, и каким боком системные библиотеки относятся к переполняющимся буферам? Все просто - первым действием атакующего обычно становится подмена адреса возврата из функции на адрес машинной команды jmp esp (FFh E4h), находящейся в доступной оперативной памяти. На машинах с задействованным аппаратным DEP'ом (блокирующим исполнение кода в стеке) приходится предварительно вызывать API-функции, присваивающие данному региону статус исполняемого или выделяющие блок памяти с нужными атрибутами и копирующие туда shell-код. Такие атаки получили название return-to-libc, поскольку впервые были реализованы на UNIX-системах, где основным «поставщиком» API-функций становится библиотека libc.lib. Ну, а в Windows хакеры используют прямой вызов KERNEL32.DLL, которая теперь загружается по случайному адресу, и атакующий имеет 1/256 шанс на удачу. В противном случае произойдет исключение, и работа уязвимого приложения будет завершена в аварийном режиме, что не есть хорошо.

Да, не слишком-то надежная защита. Если в сети находится 1000 уязвимых машин, то в первой же итерации атаки заражаются примерно 4 из них. Фактически, «тасовка» системных библиотек лишь увеличивает количество попыток, которые необходимо предпринять атакующему, но не препятствует самой атаке в принципе. К тому же, если уязвимый исполняемый файл (или принадлежащие ему динамические библиотеки) не используют флаг рандомизации, то вместо прямых вызовов KERNEL32.DLL атакующий может использовать таблицу импорта или RTL файла-жертвы. Теоретически, взвести бит рандомизации можно и в hiew'е, но практически все старое программное обеспечение останется уязвимым и продолжит оставаться таковым до тех пор, пока не появятся линкеры, поддерживающие данную фичу, и разработчики не пересоберут свои проекты. Но случится подобное не скоро, к тому же загрузка исполняемого файла по случайному адресу требует наличия fixup'ов (так же называемых перемещаемыми элементами), что увеличивает размер exe-файла и замедляет его загрузку. Беглый опрос разработчиков показал, что никто из них не собирается задействовать рандомизацию ни сейчас, ни даже когда она будет поддерживаться VC и другими компиляторами.