Автор: (c)Крис Касперски
Рисунок 1. Спрашивайте книгу
"Техника сетевых атак" в магазинах города или Интернет-магазинах.
Купить на "Озоне":
http://www.o3.ru/detail.cfm/ent=2&id=13468.
В этой главе:
Атаки, основанные на ошибках программной реализации, получили широкое распространение, а их интенсивность с течением времени продолжает неуклонно увеличиваться. Огромная сложность программного обеспечения, частые выходы новых версий - все это приводит к ухудшению качества программного кода и небрежности его тестирования. Большинство фирм, стремясь привлечь внимание потребителей, выбрасывают на рынок сырые продукты, "доводимые до ума" в процессе их эксплуатации. Такая схема создает благоприятную почву для деятельности злоумышленников, которые используют ошибки разработчиков для блокирования и проникновения на локальные и удаленные узлы сети.
Один из типов программных ошибок получил название "переполнение буфера" (buffer overflows). В общих чертах его суть заключается в следующем: если программист выделяет буфер фиксированного размера и заносит в него динамические данные, не убедившись, достаточно ли свободного места для их размещения или нет, то не поместившиеся в буфере данные вылезут за его границы и попадут в ячейки памяти, расположенные за концом буфера. Переменные, расположенные в этих ячейках, окажутся искаженными, а поведение программы станет непредсказуемым. Если буфер расположен в стеке, существует возможность перезаписи адреса возврата из функции, что приводит к передаче управления на незапланированный разработчиком участок кода!
Процесс вызова функции, передача параметров и размещение локальных переменных варьируется от языка к языку и зависит от конкретного компилятора, но в целом выглядит приблизительно так: в стек заносятся параметры и значение регистра-указателя стека уменьшается, т.е. стек растет от больших адресов к меньшим адресам; затем в стек помещается адрес инструкции, следующей за командой вызова подпрограммы (в микропроцессорах серии Intel 80x86 для этой цели служит инструкция CALL) и управление передается вызываемой подпрограмме.
Ячейка памяти, в которой хранится адрес возврата, всегда доступна вызываемой подпрограмме для модификации. А локальные переменные (в том числе и буфера) располагаются компилятором в адресах, лежащих выше [1] этой ячейки. Например, состояние стека при вызове функции myfunct():
схематично можно изобразить так:
Смещение от кадра стека | Содержимое ячеек |
0 | A |
1 | buf[0] |
2 | buf[1] |
3 | buf[2] |
4 | buf[3] |
5 | buf[4] |
6 | B |
7 | Адрес возврата |
8... | Стек функции, вызвавшей myfunct() |
Попытка записи в ячейку buff[6] приведет к искажению адреса возврата, и после завершения работы функции myfunct() произойдет передача управления на совершенно незапланированный разработчиком участок кода и, скорее всего, дело кончится повисанием. Все было бы иначе, если бы компилятор располагал локальные переменные ниже ячейки, хранящей адрес возврата, но эта область стека уже занята - она принадлежит функции, вызвавшей myfunct. Так уж устроен стек - он растет снизу вверх, но не наоборот.
Пример, приведенный ниже, служит наглядной иллюстрацией ошибки программиста, известной под названием "срыва стека" (на диске, прилагаемом к книге, он расположен в файле "/SRC/buff.demo.c"):
На первый взгляд, программа как будто бы должна работать нормально. Но функция gets(), читающая строку с клавиатуры, не имеет никаких представлений о размере выделенного под нее буфера и принимает данные до тех пор, пока не встретит символ возврата каретки. Если пользователь введет в качестве своего имени строку, превышающую десять символов [2], ее "хвост" затрет адрес возврата функции и дальнейшее выполнение программы окажется невозможным.
Например, если запустить этот пример под управлением Windows 2000 и в качестве имени пользователя ввести строку "1234567890qwerty" операционная система выдаст следующее сообщение, предлагая либо завершить работу приложения, либо запустить отладчик (если он установлен) для выяснения причин сбоя: "Исключение unknown software exception (0xc000001) в приложении по адресу 0x0012ffc0":
Рисунок 72. Реакция системы на переполнение буфера.
Допустим, в программе присутствует некая функция (условно названная "root"), которая выполняет действия, необходимые злоумышленнику. Может ли он специально подобранной строкой изменить адрес возврата таким образом, чтобы вместо сообщения о неправильно набранном пароле, управление передавалось на эту функцию?
Для ответа на такой вопрос необходимо знать - по какому адресу расположена интересующая злоумышленника функция и какой именно байт из введенной строки затирает адрес возврата. Выяснить это можно с помощью дизассемблирования кода программы.
Дизассемблирование - процесс сложный и требующий от исследователя хороших знаний ассемблера, архитектуры операционной системы и техники компиляции кода. Без этого разобраться с алгоритмом работы программы практически невозможно. К сожалению, практически не существует литературы, посвященной дизассемблированию, поэтому в большинстве случаев приходится осваивать эту тему самостоятельно [3].
Все, сказанное ниже, рассчитано на читателя средней квалификации, как минимум знающего назначение наиболее употребляемых команд микропроцессора Intel 80x86. В качестве дизассемблера выбрана IDA PRO четвертой версии [4], однако можно воспользоваться и другими инструментами, такими как SOURCER, W32Dasm или, на худой конец, DumpBin, который поставляется с любым Windows-компилятором.
Результат дизассемблирования buff.demo.exe показан ниже (на диске, прилагаемом к книге, он расположен в файле "/LOG/buff.demo.lst"). Исследователь должен изучить "устройство" функции Auth, (как ее найти во многокилобайтовом листинге - тема отдельного разговора). Для облегчения понимания листинг снабжен подробными комментариями.
Анализ кода позволил установить, что искомая функция располагается по адресу, равному 0x401000, а шестнадцатый символ имени пользователя затирает завершающим строку нулем младший байт адреса возврата.
Для передачи управления на функцию root() необходимо подменить адрес возврата на ее адрес. Поскольку адрес возврата, уже содержащийся в стеке, равен 0х401081, а адрес функции root() равен 0x401000, для достижения поставленной цели достаточно всего лишь обнулить младший байт. Если ввести строку длиной 16 символов (неважно каких), завершающий ее нуль придется как раз на младший байт сохраненного в стеке регистра EIP и инструкция retn передаст управление на функцию root().
Если на запрос имени пользователя ввести, например, такую строку, то на экран выдастся приветствие "Hello, Root!", подтверждающие факт передачи управления функции root(), что не было предусмотрено разработчиком.
Однако сразу же после завершения функции root(), программа "грохается" и операционная система выдает сообщение об исключительной ситуации, предлагая завершить работу приложения (смотри Рисунок 73). (Реакция операционной системы зависти от самой операционной системы, данный скриншот иллюстрирует поведение Windows 2000):
Рисунок 73. Реакция операционной системы на подмену адреса возврата адресом функции Root.
Исключение происходит из-за нарушения балансировки стека, ведь перед передачей управления функции Root в стек не был занесен адрес возврата! Но команда retn в строке 0x401011, "не зная" этого, снимает со стека первое попавшееся ей "под руку" двойное слово и передает на него управление.
Если нажать клавишу "отмена", операционная система запустит отладчик (конечно, при условии, что он установлен в системе). Стек, просмотренный с его помощью, должен выглядеть следующим образом (область стека, принадлежащая функции start(), не показана, поскольку в данном случае не представляет никакого интереса):
Ниже всех в стеке находится адрес возврата из процедуры "main" (0x401262), за ним следует значение регистра EBP (0x12FFC0), сохраненное в функции main() командной PUSH EBP в строке 0х40106C, затем идет модифицированный адрес возврата из функции "Auth" (0x401000), а выше расположен буфер, содержащий имя пользователя.
При выходе из функции Auth() команда retn снимает двойное слово из стека (равное теперь 0x401000) и передает на него управление. Но при выходе из функции root() команда retn извлекает двойное слово, равное 0x12FFC0 и передает на него управление. По этому адресу находятся случайные данные, поэтому поведение программы становится непредсказуемым.
Однако это не уменьшает значимости того факта, что функция Root получила управление (чего не могло произойти при нормальном ходе вещей) и была успешно выполнена. Аварийное завершение приложения - побочный эффект такой операции. Он приводит к блокировке ресурса, демаскирует атакующего и позволяет администратору системы установить, что же с ней произошло, поэтому такой подход в некоторых случаях неприемлем.
Кроме того, вовсе не факт, что в атакуемом коде всегда будет присутствовать функция, удовлетворяющая потребности злоумышленника. Но существует возможность передать управление на свой код! Для этого достаточно скорректировать адрес возврата таким образом, чтобы он указывал на начало [5] буфера, содержащего введенную пользователем строку. Тогда эта строка станет интерпретироваться как машинный код и выполнится прямо в стеке (не все микропроцессоры и не все операционные допускают выполнение кода в стеке, но в подавляющем большинстве случаев такой трюк возможен).
Для того, чтобы передать управление на начало буфера, необходимо знать его адрес. Дизассемблирование в этом вряд ли поможет, поскольку не дает представления о значении регистра ESP в момент вызова программы, поэтому необходимо воспользоваться отладчиком. Для платформы Windows хорошо себя зарекомендовал Soft-Ice от NuMega, но для экспериментов, описываемых в книге, вполне подойдет и отладчик, интегрированный в Microsoft Visual Studio.
Установив точку останова в строке 0x0401028, необходимо запустить программу на выполнение и, дождавшись "всплытия" отладчика, посмотреть на значение регистра EAX. Предыдущая команда только что занесла в него адрес буфера, предназначенного для ввода имени пользователя. Под Windows 2000 он равен 0x12FF6C, но под Windows 98 - 0x63FDE4. Это происходит по той причине, что нижняя граница стека в различных операционных системах разная. Поэтому, программные реализации атак подобного типа очень чувствительны к используемой платформе.
В двадцать восемь байт двух буферов (и еще четыре байта регистра EBP дополнительно) очень трудно затолкать код, делающий нечто полезное, однако в подавляющем большинстве случаев в атакуемых программах присутствуют буфера гораздо большего размера. Но для демонстрации принципиальной возможности передачи своего собственного кода на сервер вполне достаточно выполнить одну команду "MOV EAX,1", заносящую в регистр EAX ненулевое значение. Тогда, независимо от введенного пароля, аутентификации будет считаться успешной, ибо:
Строка, передающая управление на начало буфера имени пользователя, под Windows 2000 в шестнадцатеричном представлении должна выглядеть так: "?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 6C FF 12", а под Windows 98 (Windows 95) так: "?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? E4 FD 63".
Опкод команды "MOV EAX, const" равен "B8 x x x x", где "x" обозначает каждый байт константы. Так, например, "MOV EAX, 0x31323334" в шестнадцатеричном представлении выглядит так: "B8 34 33 32 31".
Вернуть управление основному телу программы можно множеством способов - например, воспользоваться командной перехода JMP. Но конструкция "JMP label" неудобна в обращении, поскольку в микропроцессорах серии Intel 80x86 метка представляет собой относительное смещение, отсчитываемое от адреса следующей за JMP команды. Т.к. расположение стека (а вместе с ним и команды JMP) варьируется в зависимости от операционной системы, то полученный код окажется системно-зависимым. Поэтому лучше воспользоваться регистровой адресацией: "JMP reg", где reg - 32-разрядный регистр общего назначения.
Однако на передаваемый во вводимой строке код наложены определенные ограничения. Например, с клавиатуры невозможно ввести символ нуля, поэтому команду MOV REG, 0x00401081 [6] использовать не получится. Для решения этой проблемы необходимо найти регистр, уже содержащий нуль в старшем байте. При помощи отладчика нетрудно убедиться, что старшие 16 бит регистра ECX равны "0x40", поэтому остается скорректировать младшее слово командой MOV CX,0x1018. В результате получается следующий код:
Перевести ассемблерный листинг в машинный код можно, например, с помощью утилиты HIEW, предварительно переведя его в 32-разрядный режим. Если все сделать правильно, в результате работы должно получиться следующее:
А строка, которую необходимо набрать вместо имени пользователя в шестнадцатеричном представлении полностью выглядит так: "B8 34 33 32 31 66 B9 81 10 FF E1 ?? ?? ?? ?? ?? 6C FF 12 [7], где "??" - любой байт. Некоторые из этих символов невозможно непосредственно ввести с клавиатуры, поэтому приходится прибегать к помощи клавиши Alt.
Другой способ заключается в использовании перенаправления ввода. Для этого необходимо создать файл приблизительно следующего содержания (на диске, прилагаемом к книге, он расположен в директории "/SRC" и называется "buff.demo.2000.key"):
Он состоит из двух строк, завершаемых последовательностью <CRLF>, представляющих собой имя пользователя и пароль. А запускать его необходимо следующим образом: "buff.demo.exe < buff.demo.2000.key". После завершения работы программы экран должен выглядеть приблизительно так:
Таким образом, ошибка программиста привела к возможности передачи управления на код злоумышленника и позволила ему проникнуть в систему еще на стадии аутентификации! Кстати, некоторые версии UNIX содержали ошибку переполнения буфера при вводе имени пользователя или пароля, поэтому рассмотренный выше пример трудно назвать надуманным.
Поскольку при запуске программы из-под Windows 98, буфер имени пользователя располагается по другому адресу, то необходимо скорректировать адрес возврата с 0x12FF6C на 0x63FDE4 (кстати, в Windows 98 не работает клавиша Alt и единственный путь ввести строку - воспользоваться перенаправлением ввода):
Однако при попытке ввода такой строки происходит аварийное закрытие приложения. Отладчик позволяет установить, что управление получает не требуемый код, а какой-то непонятный мусор. Оказывается, операционная система Windows 98 портит содержимое стека, расположенное выше указателя (т.е. в младших адресах). Такое поведение является вполне нормальным, поскольку сохранность памяти, лежащей выше указателя стека не гарантируется. Экспериментально удается установить, что с адреса 0x63FDE8 начинается неиспорченный "кусочек" стека, который пригоден для размещения кода.
Одина из возможных реализаций атаки, работающей под управлением Windows 98, показана ниже (на диске, прилагаемом к книге, она содержится в файле "/SRC/buff.demo.98.key"):
Четыре байта в начале строки - произвольны. Они необходимы лишь затем, чтобы сместить исполняемый код в непортящийся регион стека. Соответственно, необходимо скорректировать адрес возврата, передавая управление не на начало буфера (которое окажется затертым), а на первый байт исполняемого кода.
Ниже приведен результат использования такой строки под управлением Windows 98. Это работает! (При перенаправлении ввода вводимая строка не отображается на экране, потому имя и пароль отсутствуют):
Для предотвращения переполнения буфера программистам рекомендуют использовать функции, позволяющие явно указывать максимальное количество считываемых с клавиатуры символов. Но этот прием сам по себе еще не гарантирует неуязвимость приложения. Например, в примере, приведенном ниже, на первый взгляд все как будто бы нормально (на диске, прилагаемом к книге, этот пример содержится в файле "/SRC/buff.printf.c"):
Все строки, читаемые как с клавиатуры, так и из файла паролей, гарантированно влезают в отведенный им буфер и ни при каких обстоятельствах не могут выйти за его границы. При условии, что у злоумышленника нет доступа к файлу "buff.psw", содержащего пароли пользователей [8], он никак не сможет обойти защиту [9]. Кажется, в десятке строк трудно ошибиться и никаких дыр тут нет.
Психологическая инерция подводит и на этот раз. И, видимо, не только разработчиков, но в том числе и злоумышленников, поскольку тип атаки, описанный ниже, не получил большого распространения. Поэтому многие из приложений, считающиеся защищенными, все же содержат грубые ошибки, позволяющие легко и незаметно проникнуть в систему.
Речь идет о "большой дыре" в функции "printf", вернее дыра находится не в одной конкретной функции (тогда бы она могла бы быть безболезненно устранена), а в самом языке Си. Одни из его недостатков заключается в том, что функция не может определить, сколько ей было передано параметров. Поэтому функциям с переменным количеством аргументов приходится каким-то образом передавать и число этих самых аргументов.
Функция "printf" использует для этой цели строку спецификаторов и ее вызов может выглядеть, например, так: "printf("Name: %s\nAge: %d\nIndex: %x\n",&s[0],age,index)". Количество спецификаторов должно быть равно количеству передаваемых функции переменных. Но что произойдет, если равновесие нарушится?
Возможно два варианта - переменных больше, чем спецификаторов и переменных меньше, чем спецификаторов. Пока количество спецификаторов не превышает количества переданных параметров, не происходит ничего интересного, поскольку из стека аргументы удаляются не самой функцией, а вызывающим ее кодом (который уж наверняка знает, сколько аргументов было передано), разбалансировки стека не происходит и все работает нормально. Но если количество спецификаторов превышает количество требуемых аргументов, функция, пытаясь прочитать очередной аргумент, обратится к "чужим" данным! Конкретное поведение кода зависит от компилятора и содержимого стека на момент вызова функции "printf".
Сказанное будет рассмотрено ниже на примере следующей программы (на диске, прилагаемом к книге, она находится в файле "/SRC/printf.bug"):
Если ее откомпилировать с помощью Microsoft Visual Studio 5.0-6.0, результат работы окажется следующий:
Программа выдала два числа, несмотря на то, что ей передавали всего одну переменную 'a'. Каким же образом она сумела получить значение 'b'? (а в том, что '777' - это действительно значение переменной 'b' сомневаться не приходится). Ответить на этот вопрос помогает дизассемблирование:
Итак, содержимое стека на момент вызова функции printf такое (смотри комментарии к дизассемблированному листингу) [10]:
Но функция не знает, что ей передали всего один аргумент, ведь строка спецификаторов требует вывести два ("%x %x). А поскольку аргументы в Си заносятся в стек слева направо, самый левый аргумент расположен в стеке по наибольшему адресу. Спецификатор "%x" предписывает вывести машинное слово [11], переданное в стек по значению. Для сравнения - вот как выглядит стек на момент вызова функции "printf" в следующей программе (на диске, прилагаемом к книге, она расположена в файле "/SRC/printf.demo.c"):
Дизассемблированный листинг в книге не приводится, поскольку он практически ничем не отличается от предыдущего (на диске, прилагаемом к книге, он расположен в файле "/SRC/printf.demo.lst").
В стеке по относительному смещению [12] +4 расположен второй аргумент функции. Если же его не передать, то функция примет за аргумент любое значение, расположенное в этой ячейке.
Поэтому несмотря на то, что функции была передана всего лишь одна переменная, она все равно ведет себя так, как будто бы ей передали полный набор аргументов (а что ей еще остается делать?):
Разумеется, в нужном месте стека переменная 'b' оказалась по чистой случайности. Но в любом случае - там были бы какие-то данные. Определенным количеством спецификаторов можно просмотреть весь стек - от верхушки до самого низа! Весьма велика вероятность того, что в нем окажутся данные, интересные злоумышленнику. Например, пароли на вход в систему.
Теперь становится понятной ошибка, допущенная разработчиком buff.printf.c. Ниже приведен дизассемблированный листинг с подробными пояснениями (на диске, прилагаемом к книге, он находится в файле "/SRC/demo.printf.lst"):
Таким образом, состояние стека на момент вызова функции pritnf следующее (передаваемый аргумент выделен жирным шрифтом):
Если спецификаторов окажется больше, чем параметров, то функция начнет читать... содержимое буфера, в котором находится оригинальный пароль! По чистой случайности он оказался на верхушке стека, но даже если бы он был расположен ниже, это не изменило бы положения вещей, поскольку функции "printf "доступен весь кадр стека.
В программе функция вызывается без спецификаторов "printf(&buff[0])", но, ей передается указатель на начало буфера buff, который содержит сырую, нефильтрованную строку, введенную пользователем в качестве пароля, а она может содержать все, что угодно, в том числе и спецификаторы.
Следующий эксперимент демонстрирует, как можно использовать такую ошибку программиста для проникновения в систему (то есть, подсматривания эталонного пароля, считанного из файла):
Для "расшифровки" ответа программы необходимо перевернуть каждое двойное слово, поскольку в микропроцессорах Intel младшие байты располагаются по меньшим адресам. В результате этого получается следующее:
Рисунок 74. Расшифровка ответа программы.
Таким образом, искомый пароль равен "K98PN*". Если ввести его в программу (с соблюдением регистра), то результат ее работы должен выглядеть так:
Попытка использования спецификатора "%s" приведет вовсе не к выводу строки в удобочитаемом виде, а аварийному завершению приложения. Это продемонстрировано на рисунке, приведенном ниже:
Рисунок 75. Реакция системы на использование спецификатора %s.
Такое поведение объясняется тем, что функция, встретив спецификатор "%s", ожидает увидеть указатель на строку, а не саму строку. Поэтому происходит попытка обращения по адресу 0x5038384B ("K98PN" в символьном представлении), который находится вне пределов досягаемости программы, что и вызывает исключение.
Спецификатор "%s" пригоден для отображения содержимого указателей, которые также встречаются в программах. Это можно продемонстрировать с помощью следующего примера [13] (на диске, прилагаемом к книге, он содержится в файле "/SRC/buff.printf.%s.c"):
На этот раз буфера размещены не в стеке, а в куче - области памяти, выделенной функцией malloc и в стеке считанного пароля уже не содержится. Однако вместо самого буфера в стеке находится указатель на него! Используя спецификатор "%s", можно вывести на экран строку, расположенную по этому адресу. Например, это можно сделать так:
Кроме того, с помощью спецификатора "%s" можно получить даже код (и данные) самой программы! Другими словами, существует возможность прочитать содержимое любой ячейки памяти, доступной программе. Это происходит в том случае, когда строка, введенная пользователем, помещается в стек (а это происходит очень часто). Пример, приведенный ниже, как раз и иллюстрирует такую возможность (на диске, прилагаемом к книге, он находится в файле "/SRC/buff.pritnf.dump.c"):
Строка "%x%sXXXX" выдаст на экран строку, расположенную по адресу "XXXX". Спецификатор "%x" необходим, чтобы пропустить четыре байта, в которых расположена подстрока "%x%s". На сам же адрес "XXXX" наложены некоторые ограничения. Так, например, с клавиатуры невозможно ввести символ с кодом нуля.
Следующий пример выдает на экран содержимое памяти, начиная с адреса 0x401001, в виде строки (то есть, до тех пор, пока не встретится нуль, обозначающий завершение строки). Примечательно, что для ввода символов с кодами 0x1, 0x10 и 0x40 оказывается вполне достаточно клавиши Ctrl.
Четыре первые байта ответа программы выданы спецификатором "%x", а последние представляют собой введенный указатель. А сама строка расположена с пятого по тринадцатый байт. Если ее записать в файл и дизассемблировать, например, с помощью qview, то получится следующее (последний байт, очевидно, равен нулю, поскольку именно он послужил концом строки):
А вот как выглядит результат дизассемблирования файла demo.printf.dump.exe с помощью IDA:
Нетрудно убедится в том, что они идентичны. Манипулируя значением указателя, можно "вытянуть" весь код программы. Конечно, учитывая частоту появления нулей в коде, придется проделать огромное множество операций, прежде чем удастся "перекачать" программу на собственный компьютер. Но, во-первых, процесс можно автоматизировать, а во-вторых, чаще всего существуют и другие пути получения программного обеспечения, а наибольший интерес для вторжения на чужой компьютер представляют весьма компактные структуры данных, как правило, содержащие пароли.
Спецификатор "%c" читает двойное слово из стека и усекает его до байта. Поэтому в большинстве случаев он оказывается непригоден. Так, если в примере buff.printf.demo попытаться заменить спецификатор "%x" на спецификатор "%c", результат работы будет выглядеть так:
Программа выдала не первый и второй символы пароля, а... первый и пятый! Поэтому от надежды получить пароль в удобочитаемом виде приходится отказываться, возвращаясь к использованию спецификатора "%x".
Описанная методика, строго говоря, никаким боком не относится к переполнению буфера и никак не может воздействовать на стек. Однако чтение содержимого стека способно нанести не меньший урон безопасности системы, чем традиционное переполнение буфера. О существовании уязвимости в функции printf догадываются не все программисты, поэтому-то большинство приложений, считающиеся надежными, могут быть атакованы подобным образом.
Для устранения угрозы проникновения в систему, некоторые разработчики пытаются фильтровать ввод пользователя. Но это плохое решение, поскольку пользователь вполне может выбрать себе пароль наподобие "Kri%s" и будет очень удивлен, если система откажется его принять. Но существует простой и элегантный выход из ситуации, который продемонстрирован в листинге, приведенном ниже: (на диске, прилагаемом к книге, он находится в файле "/SRC/buff.printf.nobug.c"):
От файла demo.printf.c он отличается всего одной строкой, которая выделена жирным шрифтом. Только самый левый аргумент функции printf может содержать в себе спецификаторы, во всех остальных случаях они будут проигнорированы. Это доказывает следующий эксперимент:
Теперь никакая строка, введенная пользователем, не сможет вызвать непредсказуемого поведения программы! И нет никакой необходимости прибегать к фильтрации ввода, которая сама по себе чревата внесением новых ошибок! Для выявления всех уязвимых мест в программе достаточно воспользоваться шаблонным поиском.
Ошибки, приводящие к переполнению буфера, выявить сложнее. Попытка протестировать программу на строках непомерной длины не всегда дает желаемый результат. Во многих случаях ошибки проявляются только при вводе строк определенной длины. Как раз такую ситуацию и демонстрирует следующий пример (на диске, прилагаемом к книге, он находится в файле "/SRC/buff.arg.c"):
Это ошибка особенно распространена среди начинающих программистов, но порой встречается и у профессионалов. Строка длиной в десять байт не может поместиться в десятибайтовый буфер, поскольку на ее конце находится завершающий нуль! В результате один байт "вылезает" из буфера! Но все строки длиннее десяти символов отсекаются программой и ошибка проявляется только на десятисимвольных строках!
Ошибка переполнения в один байт встречается достаточно часто. К этому приводит путаница между длинами и индексами массивов, начинающихся с нуля; выполнение операции сравнения до модификации переменной; небрежное обращение с условиями выхода из цикла и т.д. Существует даже шуточное выражение "ошибка в плюс-минус один байт!", один из способов устранения которой заключается в подгонке значения "капризных" переменной уменьшением или увеличением их значения на единицу.
Например, если "if (p > strlen(str)) break" не работает, то некоторые программисты "прыгают блохой" на единицу назад "if (p > (strlen(str) - 1)) break" [14]. Но если "ошибка в плюс-минус один байт" не проявит себя на тестовых прогонах программы, она имеет шанс дожить до финальной версии и вместе с ней попасть на компьютер потенциальной жертвы.
С переполнением в один байт "сорвать стек" невозможно, поскольку чтобы "дотянуться" до адреса возврата в большинстве случаев требуется "пересечь" сохраненное значение регистра EBP [15], занимающее четыре байта. Но ведь именно этот факт и можно использовать для атаки! Потом, переполняющийся буфер не всегда располагается на вершине стека. Скорее всего, за ним следуют некие локальные переменные, искажение значения которых может привести к нарушению нормальной работоспособности программы: от зависания до возможности несанкционированного вторжения в систему.
В примере, приведенном ниже (на диске, прилагаемом к книге, он находится в файле "/SRC/buff.var.c"), используется переменная-флаг noguest, нулевое значение которой открывает доступ в систему всем желающим:
Дизассемблирование позволяет установить, что переменная "noguest" расположена в "хвосте" буфера buff и может быть искажена при его переполнении. Поскольку, при проверке длины строки допущена ошибка "if (strlen(argv[a]) > 16)...", завершающий ноль шестнадцатисимвольной строки обнулит значение переменной "noguest" и откроет злоумышленнику путь в систему. Это демонстрирует следующий эксперимент:
Но если увеличить длину строки хотя бы на один байт, программа отбросит ее как неправильную:
Конечно, вероятность возникновения подобной ситуации на практике очень мала. Для атаки необходимо неблагоприятное стечение многих маловероятных обстоятельств. Размер буфера должен быть кратен величие выравнивания, иначе переполняющий байт запишется в "черную дыру" [16] и ничего не произойдет. Следующая за буфером переменная должна быть критична к обнулению, т.е. если программист открывал бы доступ на машину при ненулевом значении флага guest, опять бы ничего не произошло. Поэтому в большинстве случаев несанкционированного доступа к машине получить не удастся, а вот "завесить" ее гораздо вероятнее.
Например, следующий код (на, диске, прилагаемом к книге, он находится в файле "/SRC/buff.var.2.c"), в отличие от предыдущего, трудно назвать искусственным и "притянутым за уши":
Переполнение буфера вызовет запись нуля в счетчик цикла 'a', в результате чего цикл никогда не достигнет своего конца, а программа "зависнет". А если буфер окажется расположенным в вершине стека, то "вылетевший" за его пределы ноль исказит значение регистра EBP. Большинство компиляторов генерируют код, использующий для адресации локальных переменных регистр EBP, поэтому искажение его значения приведет к нарушению работы вызывающей процедуры.
Такую ситуацию демонстрирует следующий пример (на диске, прилагаемом к книге, он расположен в файле "/SRC/buff.ebp.c"):
Ввод строки наподобие "1234567890123456123" затрет сохраненное значение регистра EBP, в результате чего при попытке прочитать значение переменной guest произойдет обращение к совсем другой области памяти, которая, скорее всего, содержит ненулевое значение. В результате, злоумышленник сможет несанкционированно войти в систему.
Модификация сохраненного значения регистра EBP имеет побочный эффект - вместе с регистром EBP изменяется и регистр-указатель верхушки стека. Большинство компиляторов генерируют приблизительно следующие прологи и эпилоги функций (в листинге они выделены жирным шрифтом):
Сперва значение регистра ESP копируется в EBP, затем выделяется память под локальные переменные (если они есть) уменьшением ESP. А при выходе из функции ESP восстанавливается путем присвоения значения, сохраненного в регистре EBP. Если же вызываемая функция исказит значение EBP, то при выходе из функции ESP будет указывать уже не на адрес возврата, а на какой-то другой адрес и при передаче на него управления, скорее всего, произойдет исключение и операционная система приостановит выполнение программы.
Однако осмысленное искажение значение регистра EBP в некоторых случаях способно передать управление на переданный код, однако для этого необходимо, чтобы он размещался в буфере вызывающей процедуры.
Получив возможность выполнения своего кода на удаленной машине, злоумышленник, как правило, стремится запустить командный интерпретатор или пытается вызвать системные функции для повышения своего статуса или регистрации нового пользователя в системе. Модификация же кода уязвимой программы (примеры которой приведены в главе "Технология срыва стека") не всегда позволяет атакующему получить желаемый результат.
Под управлением UNIX такая операция не представляет больших сложностей. Функции ядра могут быть вызваны либо посредством программного прерывания INT 0x80 (в LINUX), либо передачей управления по особому адресу, именуемому точкой входа ядра в системах совместимых с System V, расположенного по адресу 0x0007:0x00000000. Среди системных вызовов наличествуют и функция exec, которая вкупе с fork (или даже без оной) позволяет запускать другие программы, в том числе и командный интерпретатор или в терминологии UNIX - оболочку (Shell).
Функция ядра Windows NT доступны через программное прерывание INT 0x2F, но все они "сырые" и не готовы к непосредственному использованию. Одного вызова функции ZwCreateProcess, она же NtCreateProcess (EAX=0x29, INT 0x2Fh) для создания нового потока еще не достаточно. Реализация CreateProcessA (CreateProcessW), размещенная в модуле KERNEL32.DLL, содержит много "обвязочного" кода, в чем легко убедиться, заглянув в него дизассемблером.
Запустить приложение, пользуясь только сервисом, предоставляемым прерыванием INT 0x2F можно, но требует значительного объема памяти, который атакующему, скорее всего, окажется недоступен. Поэтому приходится прибегать к вызову функций из модулей DLL. Традиционно для этого загружают выбранный модуль вызовом LoadLibray, а затем получают адрес требуемой функции с помощью GetProcAddress. Например, на Си вызов командного интерпретатора может выглядеть так:
Использование устаревшей функции "WinExec" вместо современной "CreateProcess" значительно упрощает код. Вместо десяти аргументов CreateProcess, функция WinExec имеет всего два - указатель на командную строку и статус отображения окна после запуска. Даже компилятор свободно укладывается в семьдесят с небольшим байт, оставляя простор для оптимизации:
Но сразу же возникают следующие трудности [17]: наличие нулевых символов не позволяет ввести такой код с клавиатуры. Можно, конечно, снабдить код расшифровщиком, один из примеров которого приведен в дополнении "Шифровка кода", добившись исчезновения всех нулевых символов во вводимой строке. Но и сам шифровщик потребует какое-то количество памяти, которой может попросту не хватить. Другая трудность заключается в следующем - функции LoadLibrary и GetProcAddress реализованы наполовину в NTDLL.DLL, наполовину в KERNEL32.DLL и через прерывание INT 0x2E недоступны. Прежде чем их использовать, следует загрузить KERNEL32.DLL (но с помощью чего?) и определить адрес функции GetProcAddress (например, вызовом самой GetProcAddress [18]).
После сказанного может возникнуть вопрос - как же приложения под Windows еще ухитряются работать? Существует такое понятие как неявная компоновка - подключение необходимых библиотек еще на стадии загрузки файла. Для этого необходимо перечислить все требуемые функции в секции импорта PE-файла. Именно так и поступают программисты для вызова внешних функций, а к LoadLibrary прибегают редко.
Но даже если злоумышленник и получит доступ к секции импорта (а для этого необходимо иметь право записи в исполняемый и, как правило, исполняющийся в данный момент файл [19]), то он столкнется с проблемой модифицирования готовой секции импорта, что само по себе представляет нетривиальную задачу. Наконец, если добавление новых элементов пройдет успешно, изменения возымеют силу только после последующей загрузки файла.
На самом же деле, используя ряд допущений, можно решить ту же задачу более простым путем. Одна из недокументированных особенностей Windows состоит в том, во всех процессах система проецирует модуль KERNEL32.DLL по одним и тем же адресам. Поскольку, трудно представить себе приложение, обходящееся без KERNERL32.DLL [20], то можно сделать предположение, что модуль KERNEL32 уже загружен и в вызове LoadLibrary уже нет никакой необходимости.
Сложнее избавится от использования GetProcAddress. Адреса функций KERNEL32.DLL идентичны для всех процессов, но варьируются в зависимости от версии операционной системы. Существует несколько универсальных способов, более или менее работоспособных во всех версиях, (например, попытка найти GetProcAddress в таблице импорта текущего процесса), но все они либо ненадежны, либо их реализация занимает значительное количество памяти. Поэтому ниже будет рассмотрен самый простой способ использования фиксированных адресов. Единственный его недостаток заключается в "привязанности" к конкретной версии операционной системы.
Для определения адреса функции WinExec можно воспользоваться следующим кодом (или изучить секцию импорта с помощью утилиты dumpbin, поставляемую с любым Windows-компилятором):
Под управлением Windows 2000 (сборка 2195) программа возвратит адрес 0x77E98601, в других версиях возможны иные значения. Тогда код, запускающий некую программу, может выглядеть следующим образом:
Всего шестнадцать байт, без учета длины имени файла и кода, возвращающего управление основной ветке программы.
Некоторые пояснения: поскольку функции API Windows вызываются по соглашению PASCAL, то аргументы заносятся в стек справа налево и выталкивает их из стека сама вызываемая функция. Первой передается константа WS_SHOW, равная пяти. Если передать любое другое ненулевое значение, функция все равно отработает успешно, но появится возможность избавится от трех нулей, присутствующих в двойном слове, младший байт которого равен пяти. Смещение строки, содержащей имя файла, также содержит нуль в своем старшем байте, от которого необходимо избавится. Также необходимо как-то освободиться от завершающего строку нуля.
Если приведенный выше код расположить в локальном буфере функции и передать ему управление командой ret, он окажется неработоспособным. До выхода из функции пространство стека, занятое локальными переменными, освобождается: регистр указателя верхушки стека смещается вниз на дно кадра стека, а поскольку функция WinExec интенсивно использует стек, то, с вероятностью близкой к единице, код, вызывающий WinExec, окажется уничтожен и после возврата из функции произойдет исключение, приводящее к аварийному завершению программы. Во избежание этого необходимо "поднять" указатель верхушки стека, восстанавливая кадр стека. Для этого можно воспользоваться командой "SUB ESP,??", которая в шестнадцатеричных кодах выглядит так: "83 EC ??", и не содержит нулей в старших байтах константы, поскольку ей отводится всего один знаковый байт, который может принимать значения от -0x7F до 0x7F. Если этого окажется недостаточно, можно использовать несколько команд "SUB ESP,??" или поискать какие-нибудь другие решения (которых просто море).
Избавится от нуля в смещении строки можно, например, следующим образом: запустить отладчик и установить точку останова на команде "ret". Дождавшись всплытия отладчика, выбрать регистр, старшее слово которого совпадает со смещением строки. Если же такового не окажется, можно прибегнуть к следующему приему:
Не сложнее избавится и от нуля, завершающего строку. Достаточно прибегнуть, например, к самомодифицирующемуся коду, который может выглядеть, например, следующим образом (регистр EAX должен указывать на начало строки):
Строку завершает байт 0xFF, который командой INC превращается в ноль! Разумеется, допустимо использовать и другие математические операции, например, SUB или логические XOR, AND.
Объединив все вышесказанное, можно получить код, который может выглядеть, например, так:
Вместо возращения управления основой ветке программы, в коде, приведенном выше, использовано зацикливание. Это не самое лучшее решение, однако чаще всего оно никак не отражается на работоспособности атакуемой программы, (т.е., не вешает ее), поскольку каждый подключившийся к серверу пользователь обычно обрабатывается отдельным потоком. Однако возможно значительное падение производительности, особенно хорошо заметное на однопроцессорных машинах и правильнее было бы вгонять поток в сон, например, воспользовавшись вызовом WaitForSingleObject. Но в некоторых случаях можно обойтись и без этого [21].
Пусть, например, имеется следующая программа, содержащая ошибку переполнения буфера (на диске, прилагаемом к книге, она находится в файле "/SRC/buff.cmd.c"):
Если откомпилировать этот файл с помощью Microsoft Visual Studio 6.0 и запустить под отладчиком, установив точку останова в начале процедуры Auth(), можно узнать адрес буфера в стеке, размер кадра стека и значение регистров при выходе из функции (разумеется, для этого необходимо трассировать код, пока не встретится команда ret). Отладчик в этот момент может выглядеть так:
Рисунок 76. Выяснение адреса буфера>
Значение регистра ESP в момент выхода из функции равно 0x12FF7C [22], а размер кадра стека 0x20+0x4 = 0x24 байт (четыре байта занимает сохраненное в стеке значение регистра EBP). Следовательно, адрес буфера (а он находится на вершине стека) равен 0x12FF7C ‑ 0x24 = 0x12FF58. Задав этот адрес в окне дампа памяти, можно удостовериться, что сюда действительно помещается введенная пользователем строка.
Значение регистра EDX после выхода из функции strcmp совпадает со смещением начала буфера. Поэтому код для запуска командного интерпретатора путем вызова WinExec может выглядеть так:
Смещение строки "cmd.exe" в буфере равно 0x13, следовательно, младший байт регистра EDX должен быть равен 0x58+0x13 = 0x6B. Остается вычислить адрес возврата, задаваемый 37, 38 и 39 байтами вводимой строки (размер буфера 32 байта и еще 4 байта занимает сохраненное значение регистра EBP). Он равен (с учетом обратного порядка байтов) 0x88 0xFF 0x12.
Тогда вся строка в десятичном представлении (приготовленная для ввода через Alt) будет выглядеть так (на диске, прилагаемом к книге, она находится в файле "/SRC/buff.cmd.2000.key", однако перенаправление ввода блокирует клавиатуру и в командном интерпретаторе, поэтому все же придется набирать эту строку вручную):
Если ввести его правильно и без ошибок, запустится командный интерпретатор, что и демонстрирует рисунок 77:
Рисунок 77. Демонстрация запуска командного интерпретатора.
Поскольку Windows 2000 поставляется вместе с telnet-сервером, злоумышленник получает возможность запустить cmd.exe на удаленной машине и управлять ею по своему усмотрению. Штатная поставка Windows NT 4.0 не содержит средств для поддержки такого сервиса, однако злоумышленник может передать необходимые инструкции в командной строке, например, так: "cmd.exe /k copy xxxx yyyyy", для копирования выбранного файла в доступную ему директорию.
Точно так же можно запустить и любой другой файл, не только командный интерпретатор. Однако описанный метод запуска программ привязан к конкретной версии операционной системы и код, написанный для одной из них, окажется неработоспособен в другой. В UNIX системах, совместимых с System V адреса системных вызовов стандартизированы и не меняются от версии к версии.
В дополнении "Использование срыва стека для запуска командного интерпретатора под Windows NT" к главе "Технология срыва стека" были рассмотрены некоторые способы избавления от нулей, встречающихся в исполняемом коде. Грубо их можно разделить на следующие категории:
Однако SEX-мнемоники выручают не во всех случаях; использование "мусора", оставленного вызывающий код функцией, ненадежно и не позволяет создать мобильный код [24], а использование математических операций для избавления от каждого нуля при большом количестве нулей потребует много памяти, которой может не хватить.
Поэтому часто оказывается выгоднее шифровать весь код целиком, поскольку простейший декодер занимает порядка шестнадцати байт, а каждая операция избавления от нулевой ячейки требует по крайней мере три байта (FE 42 ?? INC b, [EDX+??]). Легко посчитать, если в передаваемом коде наличествуют более шести нулевых несмежных байт, использование декодера позволяет сэкономить память.
Другое преимущество декодера заключается в упрощении кода, поскольку теперь не требуется "ломать голову", пытаясь избавится от вездесущих нулей. Например, следующая конструкция позволяет создавать мобильный код, работающий независимо от того, где он расположен в памяти:
Вызов CALL 0x5 заносит в стек значение регистра указателя команд, который содержит смещение следующей инструкции, а инструкция EAX выталкивает его из стека. Теперь появляется возможность адресовать все смещения, используя EAX (или любой другой регистр) в качестве базы.
Но вызов "CALL 0x5" содержит четыре нулевых байта, поэтому должен быть переписан таким образом, чтобы в нем не встретилось ни одного нуля. Один из возможных вариантов показан ниже:
Это не только занимает много памяти, но и усложняет написание программы, поскольку постоянно приходится помнить о "злополучных" нулях и выискивать такие комбинации, где они не встречаются. А это требует очень хорошо значения ассемблера и принципа кодирования команд микропроцессора. Декодер же способен автоматически избавиться от всех нулей, упрощая написание программы.
В простейшем случае, сердцем декодера может стать логическая операция XOR. Одно из ее свойств заключается в том, что A XOR B = (A XOR B) XOR B, т.е. повторное шифрование восстанавливает исходный текст.
Другое свойство XOR: A XOR A = 0, поэтому в качестве ключа шифрования необходимо выбрать такой байт, который бы ни разу не встречался в шифруемом коде, иначе он обратится в ноль, что недопустимо.
Один из вариантов расшифровщика приведен ниже (на диске, прилагаемом к книге, он находится в файле "/SRC/xor.bin"):
Для обеспечения мобильности все смещения вычисляются от регистра ESP, при этом он должен указывать на начало декодера. А в регистр ECX необходимо занести длину расшифровываемого фрагмента.
Например, код, запускающий командный интерпретатор в программе buff.cmd.c (смотри дополнение "Использование срыва стека для запуска командного интерпретатора под Windows NT), переписанный с использованием декодера, может выглядеть так:
Расшифровщик занимает много места и в остающееся пространство уже не удается целиком записать имя командного интерпретатора. Конечно, функция WinExec сумеет запустить файл без указания расширения, но в оставшиеся четыре байта влезет имя далеко не всякого файла. Поэтому использование декодера в этом случае явно нецелесообразно и приводится лишь для приведения работоспособной иллюстрации к главе.
Но полученный код еще не готов к употреблению. Со смещения 0х11 (первый расшифровываемый байт) по 0х23 (последний расшифровываемый байт) его необходимо зашифровать, выполнив над каждым байтом операцию XOR 0x90. Такой ключ шифрования выбран потому, что в шифруемом фрагменте нет ни одного байта, равного 0х90. Следовательно, в зашифрованной строке не окажется ни одного нуля. Другим недопустимым символом является код клавиши <ENTER>, равный 0xD. Если он встретится во вводимой строке, система воспримет его как завершение строки и прекратит ввод.
Для шифровки можно воспользоваться любой утилитой, наподобие шестнадцатеричных редакторов QVIEW (или HIEW), но нетрудно это реализовать и на языке Си. Один из простейших вариантов приведен ниже (на диске, прилагаемом к книге, он находится в файле "/SRC/buff.crypt.c"). Для упрощения понимания его работы никакие проверки не выполняются.
Полученный в результате шифровки файл должен выглядеть следующим образом (на диске, прилагаемом к книге, он находится в директории "/SRC" и называется "buff.ok")
То же самое в десятичном виде, предназначенное для ввода в компьютер с помощью клавиши Alt, выглядит так:
Если все ввести правильно и без ошибок, запустится командный интерпретатор.
Код, получаемый управление при срыве стека, запускается от имени и с привилегиями уязвимой программы. Отсюда, наибольший интерес представляют программы, обладающие наивысшими привилегиями (системные сервисы, демоны и т.д.). Это значительно сужает круг поиска и ограничивает количество потенциальных кандидатов в жертвы.
Существует некоторые методы, позволяющие предотвратить последствия срыва стека, даже при наличии грубых ошибок реализации. В главах, посвященных безопасности операционных систем UNIX и Windows NT, отмечалось, что все они разрешают выполнение кода в стеке и поэтому потенциально уязвимы или же, другими словами, чувствительны к ошибкам программного обеспечения.
На самом же деле, это не совсем верно. Существуют экзотические ядра UNIX, запрещающие подобную операцию - при попытке выполнить код, размещенный в стеке, происходит исключение, и выполнение программы прерывается. Но вместе с этим перестают работать многие легальные программы, "на лету" генерирующие код и исполняющие его в стеке [25]. Но запрет на выполнение кода в стеке не затрагивает модификацию переменных, указателей, поэтому принципиальная возможность атак по-прежнему остается. Поэтому такие ядра используются крайне редко. Тем более, вызов исключение при попытке злоумышленника проникнуть на компьютер, не самая лучшая защита [26].
Некоторые компиляторы (тот же gcc) способны генерировать код, автоматически обнаруживающий выход за границы буфера, но это вызывает снижение производительности в десятки раз и чаще всего оказывается неприемлемо.
В рамках проекта Synthetix (http://www.cse.ogi.edu/DISC/projects/synthetix) удалось найти несколько простых и надежных решений, затрудняющих атаки, основанные на срыве стека. Например, "StackGuard" - одна из "заплат" к компилятору gcc, дополняет пролог и эпилог каждой из функций особым кодом, контролирующим целостность адреса возврата. Алгоритм в общих чертах следующий: в стек вместе с адресом возврата заносится так называемый, "Canary Word", расположенный до адреса возврата. Искажение адреса возврата обычно сопровождается и искажением Canary Word, что легко проконтролировать. Соль в том, что Canary Word содержит символы "\0", CR, LF, EOF, которые не могут быть обычным путем введены с клавиатуры. А для усиления защиты добавляется случайная привязка, генерируемая при каждом запуске программы.
Такая мера действительно затрудняет атаки, но не исключает их принципиальную возможность. Существует возможность перезаписи любой области памяти как искажением регистра EBP, используемого для адресации локальные переменных, так и модификацией переменных указателей. Этого StackGuard отследить не в силах. Кроме того, если происходит переполнение буферов, в которых помещается информация, считанная из двоичного файла или принятая по сети, то отсутствует всякое ограничение на передаваемые в строке символы. А узнать значение привязки можно, например, с помощью уязвимости в функции printf (и подобным ей) и т.д.
Существуют различные способы поиска уязвимых программ. Например, с помощью дизассемблирования и тщательного изучения кода или тривиального ввода строк переменной длины. Как уже отмечалось в главе "Технология срыва стека", недостаточно ограничиться вводом максимально длинных строк. Необходимо перебирать все длины от нулевой до максимально возможной.
Манипуляция со строками разной длины - наиболее простой (но не всегда действенный) путь. Если удается подобрать строку, вызывающую исключение, то, следовательно, исследуемая программа содержит уязвимость. Но вовсе не факт, что удастся передать управление на свой код, изменить адрес возврата или каким-то иным способом проникнуть на атакуемую машину. В некоторых случаях ошибки переполнения приводят к возможности блокирования программы, но не позволяют злоумышленнику совершить никакие осмысленные действия.
Поэтому перед атакующим стоят следующие вопросы: возможно ли искажение адреса возврата таким образом, чтобы он указывал на переданную строку? Если да, то какой байт строки попадает в буфер? Большинство операционных систем при возникновении аварийной ситуации выдают информацию, способную пролить свет на причины аварии. Род и форма выдача информации варьируются от одной операционной системы к другой, но практически всегда приводится содержимое регистров, верхушки стека, инструкции, вызвавшей исключение и номера самого исключения. Этими сведениями и может воспользоваться злоумышленник, чтобы ответить на интересующие его вопросы.
Наименее информативной оказывается Windows 2000, не сообщающая ни содержимое регистров, ни состояние стека. Однако она позволяет загрузить отладчик, с помощью которого легко получить необходимую информацию. Существует также утилита "Dr. Watson", предназначенная для выяснения причин возникновения аварийных ситуаций. Она великолепно подходит для анализа уязвимых программ.
Ниже будет показано, как можно использовать эту информацию для проникновения на удаленный компьютер. Поскольку, после возникновения исключения ни одна операционная система не передает клиенту сведения о причине аварии (содержимое регистров, состояние стека), то все исследования необходимо проводить на локальной машине. Т.е. злоумышленник должен иметь физический доступ к своей жертве или установить на своем компьютере ту же самую операционную систему и то же самое программное обеспечение.
Если под управлением Windows 2000 в примере buff.demo.exe (на диске, прилагаемом к книге, он находится в файле "/SRC/buff.demo.exe") ввести строку более чем из двадцати символов 'Z' (или любых других символов), произойдет исключение и на окне появится диалоговое окно следующего содержания:
Рисунок 79. Информация, выдаваемая операционной системой Windows 2000 при возникновении исключительной ситуации.
"Инструкция по адресу 0x5a5a5a5a обратилась к памяти по адресу 0x5a5a5a5a. Память не может быть read". Код символа 'Z' равен 0x5A, следовательно, искажение адреса возврата позволило передать управление по адресу 'ZZZZ' или 0x5a5a5a5a в шестнадцатеричной форме. Но какие именно байты строки затирают адрес возврата?
Это можно узнать вводом строки с различными символами, например, "ZZZZZZZZZZZZZZZ1234567" (поскольку исключение "выплевывается" только при вводе строки длинной в шестнадцать и более символов, первые пятнадцать символов оказываются незначащими, и их значение роли не играет).
Вновь возникнет исключительная ситуация и на экране появится диалог следующего содержания (смотри рисунок 081):
Рисунок 81.
"Инструкция по адресу 0x35343332 обратилась к памяти по адресу 0x35343332. Память не может быть read". Код символа '2' - 0x32, '3' - 0x33, '4' - 0x34 и '5' - 0x35. Следовательно, в сохраненный адрес возврата попадают шестнадцатый, семнадцатый, восемнадцатый и девятнадцатый символ вводимой строки (без учета завершающего нуля).
Остается выяснить, по какому адресу расположен буфер, содержащий строку. Однако выяснить его только лишь на основе сообщаемой Windows 2000 информации невозможно. Необходимо запустить отладчик, кликнув по кнопке "отмена" (эта кнопка появляется только в том случае, если в системе установлен отладчик, например, среда Microsoft Visual C++, необходимо отметить, что SoftIce в штатной инсталляции не предоставляет такой возможности).
После всплытия окна отладчика наибольший интерес представит значение регистра указателя верхушки стека ESP. Само же содержимое стека выше регистра ESP (где и располагается веденная строка) к этому моменту чаще всего оказывается уничтожено.
На рисунке 82 показано содержимое регистров и состояния стека. Легко видеть, что в стеке на месте введенной строки находится мусор. Это происходит потому, что при возникновении исключения в стек заносятся некоторые служебные данные, затирая все на своем пути.
Рисунок 82.
Основываясь на значении регистра ESP (равного в данном случае 0x12FF80), легко вычислить адрес первого байта буфера, содержащего строку. Он равен 0x0012FF80 - 0x14 [27] = 0x0011FF6C.
Если попробовать ввести строку наподобие: "\xCCZZZZZZZZZZZZZZ\x80\xFF\x12", (код 0xCC это опкод команды INT 0x3, вызывающий отладочное исключение 0х3 - только так можно гарантировать возникновение исключения в первом же байте, получившим управление), то результат будет следующий:
Рисунок 83.
"Исключение Unknown software exception (0x800000003) в приложении по адресу 0x0012FF6C". Адрес 0x9912FF6C доказывает, что адрес возврата действительно подобран правильно и первый байт переданной строки получает управление.
Таким образом, вся информация, необходимая для вторжения на чужую машину получена и злоумышленник может приступать к программной реализации атакующего кода, примеры которого были приведены в главе "Технология срыва стека" и дополнении "Использование срыва стека для запуска командного интерпретатора под Windows NT".
Под управлением Windows 9x ту же операцию выполнить намного проще, поскольку она позволяет узнать содержимое регистров и состояние стека нажатием на клавишу "сведения". На экране отобразится диалоговое окно наподобие изображенного на следующем рисунке:
Рисунок 84.
Наибольший интерес представляет значение регистра ESP, значение которого позволяет вычислить местоположение введенной строки в стеке. Значение регистра EBP, равного 0x5A5A5A5A говорит о том, что компилятор сгенерировал код, адресующий локальные переменные с помощью регистра EBP. Вполне возможно, что модификацией сохраненного значения EBP злоумышленнику удастся проникнуть на машину или, по крайне мере, "завесить" ее.
В штатную поставку Windows 9x, Windows NT 4.x, Windows 2000 входит утилита "Dr. Watson", предназначенная для выявления причин ошибок. При возникновении аварийной ситуации она сохраняет текущее состояние некорректно работающего приложения в файл протокола, в который (в зависимости от настоек) могут входить: содержимое регистров и состояние стека, истории трассировки и т.д.
Один из примеров протокола приведен ниже [28]. Он получен после возникновения исключения в результате переполнения буфера программы buff.demo.exe:
Этот протокол полезен тем, что позволяет установить: в какой процедуре произошло переполнение буфера. В листинге знаком звездочки отмечена инструкция, следующая за командой, вызвавшей исключение:
С помощью IDA легко установить, что процедура, располагающаяся по адресу 0x40106C, представляет собой main():
Но переполнение буфера произошло в процедуре Auth, ссылок на адрес которой (0х401000) в протоколе, выданном Доктором Ватсоном вообще нет! Это происходит потому, что адрес возврата из процедуры Auth был затерт введенной строкой и Доктор Ватсон не смог определить, откуда произошел вызов. Исключение вызвала не сама функция main, а одна из вызываемых ею процедур. Установить же истинного "виновника" исключения теперь практически невозможно.
Единственной зацепкой, за которую можно ухватиться, оказываются параметры переданные функции (если они не были затерты [29]). По роду и значению параметров можно хотя бы приблизительно определить, какая функция была вызвана. По крайней мере, это позволит сузить круг поиска.
Но далеко не во всех случаях ошибки переполнения удается обнаружить перебором строк разной длины. Наглядной демонстрацией этого утверждения служит следующая программа (на диске, прилагаемом к книге, она находится в файле "/SRC/buff.src.c"):
Программа запускает файл, имя которого указано в командной строке. Попытка вызвать переполнение вводом строк различной длины, скорее всего, ни к чему не приведет. Но даже беглый анализ исходного кода позволит обнаружить ошибку, допущенную разработчиком.
Если в имени файла присутствует символ ":", то программа полагает, что имя записано в формате "протокол://путь к файлу/имя файла", и пытается выяснить какой именно протокол был указан. При этом она копирует название протокола в буфер фиксированного размера, полагая, что при нормальном ходе вещей, его хватит для вмещения имени любого протокола. Но если ввести строку наподобие "ZZZZZZZZZZZZZZZZZZZZZZ:", то произойдет переполнение буфера со всеми вытекающими отсюда последствиями:.
Рисунок 85.
Приведенный пример относится к самым простым. Но существуют более коварные ошибки, проявляющиеся лишь при стечении определенных обстоятельств и обнаружить их можно только случайно или тщательным изучением исходных кодов (а в отсутствии исходных кодов - дизассемблированием или отладкой).
В первую очередь необходимо отобразить внимание на буфера фиксированного размера, расположенные в стеке. Блоки памяти, выделяемые вызовом malloc, находятся в куче (heap) и их переполнение (даже если и имеет место) не приводит к модификации адреса возврата, сохраненного в стеке.
Но четкую инструкцию по поиску ошибок дать невозможно. Существует множество разнообразных техник и подходов к решению этой проблемы, но никакой алгоритм не в в состоянии обнаруживать все уязвимости, поскольку всегда возможно возникновение принципиально новой идеи, наподобие приема, основанного на вводе спецификаторов в строке, передаваемой функции printf [30]. Автоматизированные средства поиска научатся обнаруживать такие ошибки не раньше, чем обзаведутся искусственным интеллектом.
В сложных программах огрехи были, есть и будут всегда. Тщательное тестирование миллионов строк кода современных приложений экономически невыгодно и не практикуется ни одной компанией. С другой стороны, анализ чужого кода (а особенно в отсутствии исходных текстов) выполнить в одиночку затруднительно. Большинство ошибок обнаруживаются случайно, а не в результате целенаправленного поиска. Но существует огромное количество злоумышленников, располагающих неограниченным (ну, практически неограниченным) временем для экспериментов, поэтому новые ошибки обнаруживаются чуть ли не ежедневно (и часто по несколько в день).
[1] Т.е. в младших адресах.
[2] Порядок расположения буферов в оперативной памяти зависит от характера используемого компилятора. Например, Microsoft Visual C++ 6.0 разместит эти переменные в обратном порядке. Т.е. в данном случае к адресу возврата оказывается ближе user, а не pass.
[3] Автор, набравшись наглости, рекомендует свой собственный трехтомник "Образ мышления IDA", посвященный технике дизассемблирования.
[4] На сайте разработчика www.idapro.com находится бета-версия, пригодная для экспериментов, описанных в этой главе.
[5] Ну, впрочем не обязательно именно на начало.
[6] Адрес 0x401018 указывает на первую команду, следующую за инструкцией вызова функции Auth. Разумеется, такой выбор не единичен, и можно передать управление любой другой ветке программы.
[7] Только для Windows 2000.
[8] Для упрощения листинга из файла buff.psw читается только один пароль, а имя пользователя игнорируется.
[9] Ну, разве что, перебором паролей.
[10] Жирным шрифтом выделены аргументы функции.
[11] С этими словами одна путаница... вообще-то слово равно не 16 битам, а разрядности процессора.
[12] Относительные смещения отсчитываются от верхушки кадра стека (см. комментарии к дизассемблированному листингу программы printf.bug.c в строке 0x401003).
[13] Во избежание дублирования код, сравнивающий пароли, отсутствует.
[14] Кстати, а как себя поведет эта конструкция, встретившись со строкой нулевой длины?
[15] Некоторые компиляторы умеют адресовать локальные переменные посредством регистра ESP и значение регистра EBP не сохраняют.
[16] Так иногда программисты называют область памяти, возникающую между двумя соседними переменными в результате выравнивая одной из них.
[17] Не считая того, что далеко не каждая программа выделит в распоряжение злоумышленника сотню байт памяти.
[18] Шутка. :)
[19] А доступ к исполняющимся в данный момент файлам заблокирован.
[20] Хотя такие приложения есть и самое короткое из них состоит всего из одной команды: ret.
[21] Падает производительность? Ну и пусть себе падает. Все равно разобраться, почему она падает - слишком сложная задача для рядового администратора, который просто-напросто перезапустит систему, когда обнаружит что она "чего-то стала тормозить".
[22] При условии, что программа запущена под управлением Windows 2000.
[23] Sing Extend.
[24] Например, код вызова cmd.exe, приведенный в дополнении "Использование стека для вызова командного интерпретатора под Windows NT" не работает в тех случаях, когда значение регистра EDX окажется иным.
[25] Например - компиляторы, защиты и т.д.
[26] Поскольку блокирует дальнейшее выполнение программы, т.е. "вешает" ее.
[27] Именно двадцатый (т.е. 0x14 в шестнадцатеричной системе счисления) по счету байт строки попадает в старший байт сохраненного адреса возврата.
[28] Для экономии места пришлось пойти на некоторые сокращения и опустить незначащие фрагменты. Полный протокол содержится в файле "/LOG/buff.demo.log"
[29] Что маловероятно, поскольку завершающий строку ноль обычно записывается в старший байт адреса возврата, который равен нулю, а все данные, расположенные ниже (т.е. в старших адресах) остаются нетронутыми.
[30] "Ошибка? Это не ошибка, это системная функция!"