Крис Касперский - ТЕХНИКА СЕТЕВЫХ АТАК

Один из типов программных ошибок получил название «переполнение буфера» ( buffer overflows ). В общих чертах его суть заключается в следующем: если программист выделяет буфер фиксированного размера и заносит в него динамические данные, не убедившись, достаточно ли свободного места для их размещения или нет, то не поместившиеся в буфере данные вылезут за его границы и попадут в ячейки памяти, расположенные за концом буфера. Переменные, расположенные в этих ячейках, окажутся искаженными, а поведение программы станет непредсказуемым. Если буфер расположен в стеке, существует возможность перезаписи адреса возврата из функции, что приводит к передаче управления на незапланированный разработчиком участок кода!

Процесс вызова функции, передача параметров и размещения локальных переменных варьируется от языка к языку и зависит от конкретного компилятора, но в целом выглядит приблизительно так: в стек заносятся параметры, и значение регистра-указателя стека уменьшается, т.е. стек растет от больших адресов к меньшим адресам; затем в стек помещается адрес инструкции, следующей за командой вызова подпрограммы (в микропроцессорах серии Intel 80x86 для этой цели служит инструкция CALL) и управление передается вызываемой подпрограмме.

Ячейка памяти, в которой хранится адрес возврата, всегда доступна вызываемой подпрограмме для модификации. А локальные переменные (в том числе и буфера) располагаются компилятором в адресах, лежащих выше [306]этой ячейки. Например, состояние стека при вызове функции myfunct() схематично можно изобразить так:

– Смещение от кадра стека Содержимое ячеек

– 0 A

– 1 buf[0]

– 2 buf[1]

– 3 buf[2]

– 4 buf[3]

– 5 buf[4]

– 6 B

– 7 Адрес возврата

– 8… Стек функции, вызвавшей myfunt

Попытка записи в ячейку buff[6] приведет к искажению адреса возврата, и после завершения работы функции myfunct() произойдет передача управления на совершенно незапланированный разработчиком участок кода и, скорее всего, дело кончится повисанием. Все было бы иначе, если бы компилятор располагал локальные переменные ниже ячейки, хранящей адрес возврата, но, эта область стека уже занята, - она принадлежит функции, вызвавшей myfunct. Так уж устроен стек, - он растет снизу вверх, но не наоборот.

Пример, приведенный ниже, служит наглядной иллюстрацией ошибки программиста, известной под названием «срыва стека» (на диске, прилагаемом к книге, он расположен в файле “/SRC/buff.demo.c.”)

На первый взгляд, программа как будто бы должна работать нормально. Но функция gets(), читающая строку с клавиатуры, не имеет никаких представлений о размере выделенного под нее буфера, и принимает данные до тех пор, пока не встретит символ возврата каретки. Если пользователь введет в качестве своего имени строку, превышающую десять символов [307], ее «хвост» затрет адрес возврата функции и дальнейшее выполнение программы окажется невозможным.

Например, если запустить этот пример под управлением Windows 2000, и в качестве имени пользователя ввести строку “1234567890qwerty” операционная система выдаст следующее сообщение, предлагая либо завершить работу приложения, либо запустить отладчик (если он установлен) для выяснения причин сбоя: «Исключение unknown software exception (0xc000001) в приложении по адресу 0x0012ffc0».

Допустим, в программе присутствует некая функция (условно названная “root”), которая выполняет действия, необходимые злоумышленнику. Может ли он специально подобранной строкой изменить адрес возврата таким образом, чтобы вместо сообщения о неправильно набранном пароле, управление передавалось на эту функцию?

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

Дизассемблирование - процесс сложный и требующий от исследователя хороших знаний ассемблера, архитектуры операционной системы и техники компиляции кода. Без этого разобраться с алгоритмом работы программы практически невозможно. К сожалению, практически не существует литературы, посвященной дизассемблированию, поэтому, в большинстве случаев приходится осваивать эту тему самостоятельно [308].