Microsoft продолжила наступление на переполняющееся буфера, начатое еще в w2k, вводя в действие все новые и новые защитные механизмы, существенно (якобы) затрудняющие реализацию удаленных атак. "Новые", естественно, только для Windows. В остальных операционных системах они были реализованы задолго до появления висты и в гораздо более полным объеме.
С большим опозданием в висте появилась поддержка рандомизации адресного пространства Address Space Layout Randomization — ASLR. По умолчанию все системные библиотеки теперь загружаются по одному из 256 возможных адресов, а в заголовке исполняемых файлов появился специальный бит, указывающий должен ли он загружаться по случайному адресу или нет.
Подробности о реализации ASLR от Microsoft можно почерпнуть из blog'а Michael'я Howard'а: 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)
Листинг 1 базовые адреса некоторых системных библиотек в висте
wsock32.dll (0x73200000)
winhttp.dll (0x73760000)
user32.dll (0x770f0000)
kernel32.dll (0x77350000)
gdi32.dll (0x77190000)
Листинг 2 базовые адреса тех же самых библиотек после перезагрузки системы
Насколько этот трюк усложняет атаку? И каким боком системные библиотеки относятся к переполняющимся буферам? Все просто — первым действием атакующего обычно становится подмена адреса возврата из функции на адрес машинной команды jmp esp (FFh E4h), находящейся в доступной оперативной памяти. На машинах с задействованным аппаратным DEP'ом (блокирующим исполнение кода в стеке) приходится предварительно вызывать API-функции, присваивающие данному региону статус исполняемого или выделяющие блок памяти с нужными атрибутами и копирующие туда shell-код.