· 0012FF7C 00401000 ? было: адрес возврата из функции auth, стало: адрес функции root
· 0012FF80 0012FFC0 ? значение регистра EBP, сохраненное функцией main
· 0012FF84 00401262 ? адрес возврата из функции main
Ниже всех в стеке находится адрес возврата из процедуры “main” (0x401262), за ним следует значение регистра EBP (0x12FFC0), сохраненное в функции main() командной PUSH EBP в строке 0х40106C, затем идет модифицированный адрес возврата их функции “Auth” (0x401000), а выше расположен буфер, содержащий имя пользователя.
При выходе из функции Auth() команда retn снимает двойное слово из стека (равное теперь 0x401000) и передает на него управление. Но при выходе из функции root() команда retn извлекает двойное слово, равное 0x12FFC0, и передает на него управление. По этому адресу находятся случайные данные, поэтому поведение программы становится непредсказуемым.
Однако это не уменьшает значимости того факта, что функция Root получила управление (чего не могло произойти при нормальном ходе вещей) и была успешно выполнена. Аварийное завершение приложения - побочный эффект такой операции. Он приводит к блокировке ресурса, демаскирует атакующего и позволяет администратору системы установить, что же с ней произошло, поэтому такой подход в некоторых случаях неприемлем.
Кроме того, вовсе не факт, что в атакуемом коде всегда будет присутствовать функция, удовлетворяющая потребности злоумышленника. Но существует возможность передать управление на свой код! Для этого достаточно скорректировать адрес возврата таким образом, чтобы он указывал на начало [310] буфера, содержащего введенную пользователем строку. Тогда эта строка станет интерпретироваться как машинный код и выполнится прямо в стеке (не все микропроцессоры и не все операционные допускают выполнение кода в стеке, но в подавляющем большинстве случаев такой трюк возможен).
Для того чтобы передать управление на начало буфера необходимо знать его адрес. Дизассемблирование в этом вряд ли поможет, поскольку не дает представления о значении регистра ESP в момент вызова программы, поэтому необходимо воспользоваться отладчиком. Для платформы Windows хорошо себя зарекомендовал Soft-Ice от NuMega, но для экспериментов, описываемых в книге, вполне подойдет и отладчик, интегрированный в Microsoft Visual Studio.
Установив точку останова в строке 0x0401028, необходимо запустить программу на выполнение и, дождавшись «всплытия» отладчика, и посмотреть на значение регистра EAX. Предыдущая команда только что занесла в него адрес буфера, предназначенного для ввода имени пользователя. Под Windows 2000 он равен 0x12FF6C, но под Windows 98 - 0x63FDE4. Это происходит по той причине, что нижняя граница стека в различных операционных системах разная. Поэтому, программные реализации атак подобного типа очень чувствительны к используемой платформе.
В двадцать восемь байт двух буферов (и еще четыре байта регистра EBP в придачу) очень трудно затолкать код, делающий нечто полезное, однако, в подавляющем большинстве случаев в атакуемых программах присутствуют буфера гораздо большего размера. Но для демонстрации принципиальной возможности передачи своего собственного кода на сервер, вполне достаточно выполнить одну команду “MOV EAX,1”, заносящую в регистр EAX ненулевое значение. Тогда, независимо от введенного пароля, аутентификации будет считаться успешной, ибо:
· if (auth())
· printf("Password ok\n");
· else
· printf("Invalid password\n");
Строка, передающая управление на начало буфера имени пользователя, под 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 [311]” использовать не получится. Для решения этой проблемы необходимо найти регистр уже содержащий нуль в старшем байте. При помощи отладчика нетрудно убедиться, что старшие 16 бит регистра ECX равны “0x40”, поэтому остается скорректировать младшее слово командой MOV CX,0x1018. В результате получается следующий код:
Перевести ассемблерный листинг в машинный код можно, например, с помощью утилиты HIEW, предварительно переведя его в 32 разрядный режим. Если все сделать правильно, в результате работы должно получится следующее:
· 00000000: B834333231 mov eax,031323334;"1234"
· 00000005: 66B98110 mov cx,01081;">?"
· 00000009: FFE1 jmp ecx
А строка, которую необходимо набрать вместо имени пользователя в шестнадцатеричном представлении полностью выглядит так: “B8 34 33 32 31 66 B9 81 10 FF E1?????????? 6C FF 12 [312]”, где “??” любой байт. Некоторые из этих символов невозможно непосредственно ввести с клавиатуры, поэтому приходится прибегать к помощи клавиши Alt.
Другой способ заключается в использовании перенаправления ввода. Для этого необходимо создать файл приблизительно следующего содержания (на диске, прилагаемом к книге, он расположен в директории “/SRC” и называется “buff.demo.2000.key”)
· 00000000: B8 34 33 32 31 66 B9 81 ¦ 10 FF E1 66 66 66 66 66 ¬4321f¦Б> сfffff
· 00000010: 6C FF 12 0D 0A 0D 0A ¦ l ¦d0d0
Он состоит из двух строк, завершаемых последовательностью «CRLF», представляющих собой имя пользователя и пароль. А запускать его необходимо следующим образом: “buff.demo.exe «buff.demo.2000.key”. После завершения работы программы экран должен выглядеть приблизительно так:
· F:\TPNA\src»buff.demo.exe
· Buffer Overflows Demo
· Login:¬1234f¦Б^P с12345l ^R
· Passw:
· Password ok
Таким образом, ошибка программиста привела к возможности передачи управления на код злоумышленника и позволила ему проникнуть в систему еще на стадии аутентификации! Кстати, некоторые версии UNIX содержали ошибку переполнения буфера при вводе имени пользователя или пароля, поэтому рассмотренный выше пример трудно назвать надуманным.
Поскольку, при запуске программы из-под Windows 98, буфер имени пользователя располагается по другому адресу, то необходимо скорректировать адрес возврата с 0x12FF6C на 0x63FDE4 (кстати, в Windows 98 не работает клавиша Alt и единственный путь ввести строку - воспользоваться перенаправлением ввода):
· 00000000: B8 34 33 32 31 66 B9 81 ¦ 10 FF E1 66 66 66 66 66 ¬4321f¦Б> сfffff
· 00000010: E4 FD 63 0D 0A 0D 0A ¦ l ¦d0d0
Однако при попытке ввода такой строки происходит аварийное закрытие приложения. Отладчик позволяет установить, что управление получает не требуемый код, а какой-то непонятный мусор. Оказывается, операционная система Windows 98 портит содержимое стека, расположенное выше указателя (т.е. в младших адресах). Такое поведение является вполне нормальным, поскольку сохранность памяти, лежащей выше указателя стека не гарантируется. Экспериментально удается установить, с адреса 0x63FDE8 начинается неиспорченный «кусочек» стека, который пригоден для размещения кода.