Строка неконтролируемого формата

Строка неконтролируемого формата — это тип внедрения кода уязвимости , обнаруженной примерно в 1989 году и которую можно использовать для эксплойтов безопасности . Первоначально считавшиеся безобидными, эксплойты форматной строки могут использоваться для сбоя программы или выполнения вредоносного кода. Проблема возникает из-за использования непроверяемого пользовательского ввода в качестве параметра строки формата в некоторых функциях C , выполняющих форматирование, таких как printf(). Злоумышленник может использовать %s и %x форматировать токены, среди прочего, для печати данных из стека вызовов или, возможно, из других мест в памяти. Можно также записать произвольные данные в произвольные места, используя %n токен формата, который командует printf() и подобные функции для записи количества байтов, отформатированных по адресу, хранящемуся в стеке.

Подробности

Типичный эксплойт использует комбинацию этих методов для получения контроля над указателем инструкции (IP) процесса. например, заставив программу перезаписать адрес библиотечной функции или адрес возврата в стеке указателем на какой-то вредоносный шеллкод . Параметры заполнения для спецификаторов формата используются для управления количеством выводимых байтов и %x токен используется для извлечения байтов из стека до тех пор, пока не будет достигнуто начало самой строки формата. Начало строки формата создается так, чтобы содержать адрес, который %n токен формата может затем перезаписаться адресом вредоносного кода для выполнения.

Это распространенная уязвимость, поскольку ранее ошибки формата считались безобидными и приводили к уязвимостям во многих распространенных инструментах. MITRE По состоянию на июнь 2007 года в проекте CVE насчитывается около 500 уязвимых программ, а анализ тенденций ставит его на 9-е место по количеству зарегистрированных типов уязвимостей в период с 2001 по 2006 год.

Ошибки формата строки чаще всего возникают, когда программист хочет вывести строку, содержащую предоставленные пользователем данные (в файл, в буфер или пользователю). Программист может ошибочно написать printf(buffer) вместо printf("%s", buffer). Первая версия интерпретирует buffer как строку формата и анализирует все инструкции форматирования, которые она может содержать. Вторая версия просто выводит строку на экран, как и задумал программист. Обе версии ведут себя одинаково, поскольку в строке отсутствуют спецификаторы формата, что позволяет легко остаться незамеченной разработчиком.

Ошибки формата возникают из-за того, что соглашения о передаче аргументов в C не являются типобезопасными . В частности, varargs механизм позволяет функциям принимать любое количество аргументов (например, printf столько аргументов ), «извлекая» из стека вызовов , сколько пожелает, полагая, что ранние аргументы указывают, сколько дополнительных аргументов и каких типов необходимо извлечь.

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

История

Ошибки формата были впервые отмечены в 1989 году в ходе нечеткого тестирования , проведенного в Университете Висконсина, в результате которого был обнаружен «эффект взаимодействия» в оболочке C (csh) между ее механизмом истории команд и процедурой обработки ошибок, которая предполагала безопасный ввод строки.

Использование ошибок форматной строки в качестве атаки было обнаружено в сентябре 1999 года Тиммом Твиллманом во время аудита безопасности демона ProFTPD вектора . В ходе проверки была выявлена snprintf которые напрямую передавали сгенерированные пользователем данные без строки формата. Обширные тесты с надуманными аргументами для функций в стиле printf показали, что использование этого для повышения привилегий возможно. появилось первое сообщение Это привело к тому, что в сентябре 1999 года в списке рассылки Bugtraq об этом классе уязвимостей, включая базовый эксплойт. Однако прошло еще несколько месяцев, прежде чем сообщество безопасности осознало всю опасность уязвимостей форматной строки, поскольку начали появляться эксплойты для другого программного обеспечения, использующего этот метод. Первые эксплойты, которые привлекли внимание общественности к этой проблеме (путем предоставления удаленного root-доступа посредством выполнения кода), были одновременно опубликованы в списке Bugtraq в июне 2000 года Пшемыславом Фрасунеком. и человек под ником tf8 . Вскоре за ними последовало объяснение, опубликованное человеком под ником Lamagra . «Ошибки формата» были опубликованы в списке Bugtraq Паскалем Бушареном в июле 2000 года. Основополагающая статья «Атака на строку формата» Тимом Ньюшамом, был опубликован в сентябре 2000 года, а другие подробные технические пояснения были опубликованы в сентябре 2001 года, например, «Использование уязвимостей форматных строк » ​​команды Teso .

Предотвращение в компиляторах

Многие компиляторы могут статически проверять строки формата и выдавать предупреждения об опасных или подозрительных форматах. В коллекции компиляторов GNU соответствующими флагами компилятора являются: -Wall, -Wformat, -Wno-format-extra-args, -Wformat-security, -Wformat-nonliteral, и -Wformat=2.

Большинство из них полезны только для обнаружения строк неправильного формата, известных во время компиляции. Если строка формата может исходить от пользователя или из источника, внешнего по отношению к приложению, приложение должно проверить строку формата перед ее использованием. Также необходимо соблюдать осторожность, если приложение генерирует или выбирает строки формата на лету. Если используется библиотека GNU C, -D_FORTIFY_SOURCE=2 Параметр можно использовать для обнаружения определенных типов атак, происходящих во время выполнения. -Wformat-nonliteral проверка более строгая.

Обнаружение

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

Обнаружение в двоичных файлах, скомпилированных x86.

Подсчет количества аргументов в x86 часто упрощается благодаря соглашению о вызовах, согласно которому вызывающая сторона удаляет аргументы, помещенные в стек, путем добавления к указателю стека после вызова, поэтому простое изучение исправления стека дает число аргументы, переданные printf- семейная функция».

См. также

• Межприкладные сценарии используют подобную программную ошибку.
• Межсайтовый скриптинг
• printf
• scanf
• системный журнал
• Неправильная проверка ввода
• SQL-инъекция — это аналогичная атака, которая успешна, если входные данные не фильтруются.

Дальнейшее чтение

• Коуэн, Криспин (август 2001 г.). FormatGuard: автоматическая защита от уязвимостей строки формата printf (PDF) . Материалы 10-го симпозиума по безопасности USENIX.
• Коуэн, Криспин (январь – февраль 2003 г.), Безопасность программного обеспечения для систем с открытым исходным кодом , Безопасность и конфиденциальность IEEE, Компьютерное общество IEEE.
• Кляйн, Тобиас (2004). Переполнения буфера и уязвимости форматной строки - функциональность, эксплойты и меры противодействия (на немецком языке) (1-е изд.). dpunkt.verlag . ISBN  3-89864-192-9 . (vii+663 страницы)
• Сикорд, Роберт К. (сентябрь 2005 г.). Безопасное программирование на C и C++ . Эддисон Уэсли . ISBN  0-321-33572-4 .

Внешние ссылки

• Введение в эксплойты форматных строк , 2 мая 2013 г., Алекс Рис
• scut / team- TESO, использующая уязвимости строк формата v1.2 9 сентября 2001 г.
• Классификация угроз WASC — атаки на строку формата
• Стандарты безопасного кодирования CERT
• Инициатива CERT по безопасному кодированию
• Известные уязвимости в проекте CVE MITRE.
• Безопасное программирование с использованием GCC и GLibc. Архивировано 21 ноября 2008 г. в Wayback Machine (2008 г.), Марсель Хольтманн.