Вопрос:Переполняются только буферы? Ответ:Фактически любое неправильное использование стековых переменных может привести к переполнению буфера. Этот тип уязвимости присущ программам, написанным на языке программирования с недостаточным контролем типов используемых данных, например на языке С. В последнее время возросли последствия от переполнения буфера, о чем свидетельствуют, например, локальная компрометация 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-приложений. Один из недавно появившихся способов обнаружения уязвимости переполнения буфера основан на ревизии выполнимого кода. Ревизия выполнимого кода основана на пользовательских средствах поиска характерных комбинаций машинных команд. Пока подобных общедоступных средств мало, но в скором времени ожидается рост их числа. При желании можно изучить даже некоторые инструментальные средства атак.
Глава 9 Ошибки форматирующей строки
В этой главе обсуждаются следующие темы:
• Уязвимость форматирующей строки
• Пример уязвимой программы
• Тестирование программ способом случайной форматирующей строки
• Программа атаки с использованием форматирующей строки
· Резюме
· Конспект
· Часто задаваемые вопросы
В начале лета 2000 года специалистам в области защиты информации стало известно о новом типе уязвимости программного обеспечения. Речь идет о так называемых ошибках форматирующей строки. (Форматирующая строка – строка, используемая в операторах вывода, которая может содержать спецификации форматов и литералы.) Об ошибках форматирующей строки заговорили после 23 июня 2000 года, когда на Bugtraq была размещена программа, позволяющая атаковать FTP-демон Вашингтонского университета. При условии включения анонимного доступа к FTP, а по умолчанию в большинстве систем он включен, она позволяла удаленному злоумышленнику получить полный доступ к хостам с работающим FTP демоном Вашингтонского университета. Эта программа нанесла серьезный урон безопасности Интернет, потому что на тот момент времени FTP демон Вашингтонского университета широко использовался в сети.
У злоумышленников появилось средство удаленной компрометации десятки тысяч хостов в Интернете. Но не это повергло в шок сообщество защиты информации. Беспокойство вызвали причины, породившие новую уязвимость, которая, как выяснилось, присутствует почти во всех программах. Новая программа атаки продемонстрировала совершенно новый способ использования ошибок программирования.
Непосредственная передача входных данных программы функции printf() или включение их в форматирующую строку функции printf() приводит к ошибкам форматирующей строки. В случае с FTP демоном Вашингтонского университета функции printf() передавался аргумент команды SITE EXEC, который брался из входных данных программы демона.
О том, насколько эффективна подобная атака, говорит факт немедленного автоматического получения злоумышленником прав суперпользователя на атакованном хосте.
До появления программы атаки на FTP-демон Вашингтонского университета ошибки форматирующей строки рассматривались большинством программистов всего лишь как плохой стиль программирования, сопутствующий поспешному кодированию, и ничего более. Худшее, что происходило до этого из-за ошибок форматирующей строки, – это отказ в обслуживании. Но вскоре сообщество защиты информации изменило свое отношение к этому вопросу. Причиной компрометации многих UNIX-систем стала ошибка форматирующей строки.
Читать дальше
Конец ознакомительного отрывка
Купить книгу