Издательский дом ООО "Гейм Лэнд"СПЕЦВЫПУСК ЖУРНАЛА ХАКЕР #45, АВГУСТ 2004 г.

Лопнуть как мыльный пузырь

Vint (vint@glstar.ru)

Спецвыпуск Xakep, номер #045, стр. 045-004-4


– адрес возврата из функции помещается в стек (абсолютно все распространенные ОС и компиляторы);

– параметры функции передаются через стек (все ОС, а для Windows это – основной способ передачи параметров в API-функции);

– локальные переменные лежат в стеке (Windows- и *nix-компиляторы делают именно так);

– стек имеет идеологию FILO (так устроена платформа х86, а значит все системы, работающие на данной архитектуре, имеют такой тип стека);

– данные стека могут быть командами (одна из основ архитектуры х86 – единое адресное пространство для данных и кода);

– имеются процессы с высокими привилегиями (справедливо для любой ОС; одна из основ разграничения пользователей, базис сетевых ОС);

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

Видишь, как все сложно? Переполнение буфера – это ошибка, от которой избавиться крайне трудно, потому что главная причина кроется в основах архитектуры х86 и в базисах разработки ОС. Ни то ни другое переделать никто уже не сможет.

Теперь, когда ты, надеюсь, понял технологию таких атак, поговорим о практической стороне данного вопроса, ведь, как известно, теория без практики мертва.

Способы защиты

Учитывая, что основа атак такого типа кроется в самой идеологии архитектуры х86, легко реализуемые защиты отпадают сразу :-(. На данный момент основным способом защиты является поиск и устранение человеческих ошибок как в ПО, так и в компиляторах. Ничего принципиально другого пока не придумали. Хотя перспективные разработки имели место: несколько лет назад был выпущен патч на ядро Linux, который запрещал выполнять код в стеке, лишая атаку одного из ключевых моментов. Однако проект этот скоро загнулся по причине серьезного увлечения нестабильности системы в целом. Сейчас мы видим новые попытки реализовать идею запрета выполнения кода из области данных. В начале этого года представители AMD заявили: "Процессоры Opteron и Athlon 64 способны защитить компьютер от интернет-атак одного из самых распространенных типов – совершаемых путем вызова ошибки переполнения буфера. Как и почти все другие, процессоры AMD при переполнении буфера передают управление механизму обработки исключений. Но благодаря функции Execution Protection после этого Opteron и Athlon 64 принимают дополнительные меры: код, поступающий после вызова исключения по переполнению буфера, попросту не записывается в память и не исполняется, за счет чего блокируется деятельность троянских программ, вызывающих переполнение буфера в целях подчинения себе системы". То есть они правят архитектуру х86 на аппаратном уровне ;-). Есть приятные новости и от Intel. Совсем недавно официально объявлено о том, что начиная с процессора Prescott в степинг E0 будет добавлен новый флаг NX, запрещающий выполнение кода в стеке на аппаратном уровне. Как видим, уничтожается теоретическая основа атак на переполнения буфера, причем борются с этой ошибкой архитектуры сами производители железа. Но на сегодняшний день такой метод борьбы неэффективен: для Windows XP поддержка флага NX будет введена только в SP2, для остальных версий она вообще пока не предвидится, для Linux описание патчей уже доступно по адресу redhat.com/~mingo/nx-patches/QuickStart-NX.txt. Но отсутствие программной поддержки – не самое решающее препятствие в распространении такой защиты, главным является то, что ни один общедоступный процессор не имеет такого флага! Для процессоров AMD первый камень с такой защитой – 64-битный Athlon. А у Intel пока все в проектах: нет ни одного CPU с такой аппаратной защитой, ее обещают лишь в 64-битных реализациях и в P-IV нового степинга.

Назад на стр. 045-004-3  Содержание  Вперед на стр. 045-004-5