Признаком откровенного непрофессионализма является пренебрежение #define или безграмотное использование последних. В частности, если размер буфера buff определяется через MAX_BUF_SIZE, то и размер копируемой в него строки должен ограничиваться им же, а не MAX_STR_SIZE, заданным в отдельном define. Обращайте внимание и на характер аргументов функций, работающих с блоками данных.

Передача функции указателя без сообщения размера блока – частая ошибка начинающих, равно как и злоупотребление функциями strcpy/strncpy. Первая небезопасна (отсутствует возможность ограничить предельно допустимую длину копируемой строки), вторая ненадежна (отсутствует возможность оповещения о факте «обрезания» хвоста строки, не уместившегося в буфер, что само по себе может служить весьма нехилым источником ошибок).

Хорошо, ошибка переполнения найдена. Что дальше? А дальше только дизассемблер. Не пытайтесь выжать из исходных текстов хоть какую-то дополнительную информацию. Порядок размещения переменных в памяти не определен и практически никогда не совпадает с порядком их объявления в программе. Может оказаться так, что большинства из этих переменных в памяти попросту нет и они размещены компилятором в регистрах либо же вовсе отброшены оптимизатором как ненужные. (Попутно заметим, что все демонстрационные листинги, приведенные в этой статье, рассчитывают, что переменные располагаются в памяти в порядке их объявления.)

Впрочем, не будем забегать вперед – дизассемблирование – тема отдельной статьи, которую планируется опубликовать в следующих номерах журнала.

Цели и возможности атаки

Конечная цель любой атаки – заставить систему сделать что-то «нехорошее», чего нельзя добиться легальным путем. Существует по меньшей мере четыре различных способа реализации атаки:

n  чтение секретных переменных;

n  модификация секретных переменных;

n  передача управления на секретную функцию программы;

n  передача управления на код, переданный жертве самим злоумышленником.

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

Еще в адресном пространстве процесса содержатся дескрипторы секретных файлов, сокеты, идентификаторы TCP/IP-соединений и многое другое. Разумеется, вне текущего контекста они не имеют никакого смысла, но могут быть использованы кодом, переданном жертве злоумышленником, и осуществляющим, например, установку «невидимого» TCP/IP-соединения, прячась под «крышей» уже существующего.

Ячейки памяти, хранящие указатели на другие ячейки, «секретными» строго говоря не являются, однако, знание их содержимого значительно облегчает атаку. В противном случае атакующему придется определять опорные адреса вслепую. Допустим, в уязвимой программе содержится следующий код:

char *p = malloc(MAX_BUF_SIZE);

где p – указатель на буфер, содержащий секретный пароль. Допустим так же, что в программе имеется ошибка переполнения, позволяющая злоумышленнику читать содержимое любой ячейки адресного пространства. Весь вопрос в том: как этот буфер найти? Сканировать всю кучу целиком не только долго, но и небезопасно, т.к. можно легко натолкнуться на невыделенную страницу памяти и тогда выполнение процесса аварийно завершится. Автоматические и статические переменные в этом отношении более предсказуемы. Поэтому атакующий должен сначала прочитать содержимое указателя p, а уже затем – секретный пароль, на который он указывает. Разумеется, это всего лишь пример, которым возможности переполняющего чтения не ограничиваются.