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

Строка “%x%sXXXX” выдаст на экран строку, расположенную по адресу “XXXX”. Спецификатор “%x” необходим, чтобы пропустить четыре байта, в которых расположена подстрока “%x%s”. На сам же адрес “XXXX” наложены некоторые ограничения. Так, например, с клавиатуры невозможно ввести символ с кодом нуля.

Следующий пример выдает на экран содержимое памяти, начиная с адреса 0x401001 в виде строки (то есть, до тех пор, пока не встретится нуль, обозначающий завершение строки). Примечательно, что для ввода символов с кодами 0x1, 0x10 и 0x40 оказывается вполне достаточно клавиши Ctrl.

· buff.printf.dump.exe

· printf dump demo

· Login:%x%s^A^P@

· 73257825 ЛьГь>h0`@ O>@

Четыре первые байта ответа программы выданы спецификатором “%x", а последние представляют собой введенный указатель. А сама строка расположена с пятого по тринадцатый байт. Если ее записать в файл и дизассемблировать, например, с помощью qview, то получится следующее (последний байт очевидно равен нулю, поскольку именно он послужил концом строки):

· 00000020: 8BEC mov ebp,esp

· 00000022: 83EC10 sub esp,00000010

· 00000025: 68306040 00push 00406030

А вот как выглядит результат дизассемблирования файла demo.printf.dump.exe с помощью IDA:

· text:00401000 sub_0_401000 proc near; CODE XR

· text:00401000

· text:00401000 var_11 = byte ptr -11h

· text:00401000 var_10 = byte ptr -10h

· text:00401000

· text:00401000 55 push ebp

· text:00401001 8B EC mov ebp, esp

· text:00401003 83 EC 10 sub esp, 10h

· text:00401006 68 30 60 40 00 push offset aPrintfDumpDemo;

· text:0040100B E8 DB 01 00 00 call sub_0_4011EB

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

Спецификатор “%c” читает двойное слово из стека и усекает его до байта. Поэтому, в большинстве случаев он оказывается непригоден. Так, если в примере buff.printf.demo попытаться заменить спецификатор “%x” на спецификатор “%c” результат работы будет выгядеть так:

· buff.printf.exe

· printf bug demo

· Login:kpnc

· Passw:%c%c

· Invalid password: KN

Программа выдала не первый и второй символы пароля, а… первый и пятый! Поэтому, от надежды получить пароль в удобочитаемом виде приходится отказываться, возвращаясь к использованию спецификатора “%x”.

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

Для устранения угрозы проникновения систему некоторые разработчики пытаются фильтровать ввод пользователя. Но это плохое решение, поскольку пользователь вполне может выбрать себе пароль наподобие «Kri%s» и будет очень удивлен, если система откажется его принять. Но существует простой и элегантный выход из ситуации, который продемонстрирован в листинге, приведенном ниже: (на диске, прилагаемом к книге, он находится в файле “/SRC/buff.printf.nobug.c”):

От файла demo.printf.c он отличается всего одной строкой, которая выделена жирным шрифтом. Только самый левый аргумент функции printf может содержать в себе спецификаторы, во всех остальных случаях они будут проигнорированы. Это доказывает следующий эксперимент:

· buff.printf.nobug.exe

· printf bug demo

· Login:kpnc

· Passw: %x

· Invalid password: %x

Теперь никакая строка, введенная пользователем, не сможет вызвать непредсказуемого поведения программы! И нет никакой необходимости прибегать к фильтрации ввода, которая сама по себе чревата внесением новых ошибок! Для выявления всех уязвимых мест в программе достаточно воспользоваться шаблонным поиском.

Ошибки, приводящие к переполнению буфера, выявить сложнее. Попытка протестировать программу на строках непомерной длины не всегда дает желаемый результат. Во многих случаях ошибки проявляются только при вводе строк определенной длины. Как раз такую ситуацию и демонстрирует следующий пример (на диске, прилагаемом к книге, он находится в файле “/SRC/buff.arg.c”):

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

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

Например, если “if (p»strlen(str)) break” не работает, то некоторые программисты «прыгают блохой» на единицу назад “if (p»(strlen(str)-1)) break” [319]. Но если «ошибка в плюс-минус один байт» не проявит себя на тестовых прогонах программы, она имеет шанс дожить до финальной версии и вместе с ней попасть на компьютер потенциальной жертвы.

С переполнением в один байт «сорвать стек» невозможно, поскольку чтобы «дотянуться» до адреса возврата в большинстве случаев требуется «пересечь» сохраненное значение регистра EBP [320], занимающее четыре байта. Но ведь именно этот факт и можно использовать для атаки! Потом, переполняющийся буфер не всегда располагается на вершине стека. Скорее всего, за ним следуют некие локальные переменные, искажение значения которых может привести к нарушению нормальной работоспособности программы: от зависания до возможности несанкционированного вторжения в систему.