Читать онлайн «Защита от хакеров корпоративных сетей». Страница 73

Часто задаваемые вопросы

Наиболее часто авторы книги отвечали на приведенные ниже вопросы. Вопросы интересны тем, что они позволяют читателю лучше усвоить изложенный в главе материал и реализовать его на практике для обеспечения безопасности вычислительных систем. Если у читателя возникли вопросы по главе, зайдите на сайт www.syngress.com/solutions и щелкните мышкой на кнопке «Ask the Author».

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

Вопрос: Где можно глубже познакомиться с вопросами переполнения буфера? Ответ: Чтение списков рассылки типа Bugtraq (www.securityfocus.com) и сопутствующие статьи об атаках переполнения буфера в журналах типа «Phrack» помогут значительно углубить знания в этой области.

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

Вопрос: Переполняются только буферы? Ответ: Фактически любое неправильное использование стековых переменных может привести к переполнению буфера. Этот тип уязвимости присущ программам, написанным на языке программирования с недостаточным контролем типов используемых данных, например на языке С. В последнее время возросли последствия от переполнения буфера, о чем свидетельствуют, например, локальная компрометация Sendmail (www.securityfocus.com/bid/3163) и найденная удаленная уязвимость в SSH1 (www.securityfocus.com/bid/2347). Подобные уязвимости трудны для обнаружения автоматическим инструментарием и могут доставить серьезные проблемы в будущем.

Вопрос: Каким образом можно обнаружить переполнение буфера? Ответ: Существует ряд способов для локализации в программе ошибок переполнения буфера. При наличии исходного текста атакованного приложения можно воспользоваться рядом разнообразных инструментальных средств, предназначенных для определения проблемных участков кода. Например, ITS4 (www.cigital.com/services/its4) или FlawFinder (www.dwheeler.com/flawfinder). Но и без исходных текстов доступен ряд способов. Один из них – проверка входных данных. Многочисленные инструментальные средства пригодны для контроля полей ввода информации в программах общего применения. К ним относится компонента контроля общесетевых протоколов CHAM (common hacker attack methods – общие методы хакерских атак) программы eEye\'s Retina (www.eEye.com), написанная автором. Дэйв Айтел (Dave Aitel) из @Stake написал для API программу SPIKE (www.atstake.com/research/tools/spike-v1.8.tar.gz), которая проверяет входные данные Web-приложений. Один из недавно появившихся способов обнаружения уязвимости переполнения буфера основан на ревизии выполнимого кода. Ревизия выполнимого кода основана на пользовательских средствах поиска характерных комбинаций машинных команд. Пока подобных общедоступных средств мало, но в скором времени ожидается рост их числа. При желании можно изучить даже некоторые инструментальные средства атак.

В этой главе обсуждаются следующие темы:

• Уязвимость форматирующей строки

• Пример уязвимой программы

• Тестирование программ способом случайной форматирующей строки

• Программа атаки с использованием форматирующей строки

· Резюме

· Конспект

· Часто задаваемые вопросы

В начале лета 2000 года специалистам в области защиты информации стало известно о новом типе уязвимости программного обеспечения. Речь идет о так называемых ошибках форматирующей строки. (Форматирующая строка – строка, используемая в операторах вывода, которая может содержать спецификации форматов и литералы.) Об ошибках форматирующей строки заговорили после 23 июня 2000 года, когда на Bugtraq была размещена программа, позволяющая атаковать FTP-демон Вашингтонского университета. При условии включения анонимного доступа к FTP, а по умолчанию в большинстве систем он включен, она позволяла удаленному злоумышленнику получить полный доступ к хостам с работающим FTP демоном Вашингтонского университета. Эта программа нанесла серьезный урон безопасности Интернет, потому что на тот момент времени FTP демон Вашингтонского университета широко использовался в сети.

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

Непосредственная передача входных данных программы функции printf() или включение их в форматирующую строку функции printf() приводит к ошибкам форматирующей строки. В случае с FTP демоном Вашингтонского университета функции printf() передавался аргумент команды SITE EXEC, который брался из входных данных программы демона.

О том, насколько эффективна подобная атака, говорит факт немедленного автоматического получения злоумышленником прав суперпользователя на атакованном хосте.

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

Как упоминалось ранее, об уязвимости форматирующей строки стало известно в июне 2000 года. А атака на FTP-демон Вашингтонского университета была осуществлена злоумышленником, известным как tf8, 15 октября 1999 года. Если предположить что после этого преступникам стало известно, как ошибки форматирующей строки могут использоваться для проведения атак, то у них было более восьми месяцев для поиска и использования подобных ошибок в других программах. Эта догадка основана на предположении о том, что во время атаки на FTP-демон Вашингтонского университета впервые были использованы ошибки форматирующей строки. Хотя нет особых причин в это верить, поскольку комментарии в программе взлома не свидетельствуют о том, что их автор открыл какой-то новый способ атаки.

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

Что касается официальной классификации, ошибки форматирующей строки на самом деле нельзя выделить в отдельную категорию ошибок программного обеспечения, как, например, ошибка «состояние гонок» (race conditions) при конкуренции программ за ресурсы или переполнение буфера. Скорее, ошибки форматирующей строки относятся к категории ошибок проверки входных данных (input validation bugs). Основная причина их появления состоит в том, что программисты включают в форматирующую строку входные непроверенные данные программ.