19 смертных грехов, угрожающих безопасности программ Ховард Майкл
CVE–1999–0042
Цитата из описания ошибки: «Переполнение буфера в реализации серверов IMAP и POP Вашингтонского университета». Эта же ошибка очень подробно документирована в бюллетене CERT за номером СА–1997–09. Переполнение происходит во время аутентификации для доступа к серверам, реализующим протоколы Post Office Protocol (POP) и Internet Message Access Protocol (IMAP). Связанная с ней уязвимость состоит в том, что сервер электронной почты не мог отказаться от избыточных привилегий, поэтому эксплойт давал противнику права пользователя root. Это переполнение поставило под удар довольно много систем.
Контрольная программа, созданная для поиска уязвимых версий этого сервера, обнаружила аналогичные дефекты в программе SLMail 2.5 производства Seattle Labs, о чем помещен отчет на странице www.winnetmag.com/Article/ArticleID/9223/ 9223.html.
CVE–2000–0389 – CVE–2000–0392
Из CVE–2000–0389: «Переполнение буфера в функции krb_rd_req в Kerberos версий 4 и 5 позволяет удаленному противнику получить привилегии root».
Из CVE–2000–0390: «Переполнение буфера в функции krb425_conv_principal в Kerberos 5 позволяет удаленному противнику получить привилегии root».
Из CVE–2000–0391: «Переполнение буфера в программе krshd, входящей в состав Kerberos 5, позволяет удаленному противнику получить привилегии root».
Из CVE–2000–0392: «Переполнение буфера в программе krshd, входящей в состав Kerberos 5, позволяет удаленному противнику получить привилегии root».
Эти ошибки в реализации системы Kerberos производства МТИ документированы в бюллетене CERT СА–2000–06 по адресу www.cert.org/advisories/CA–2000–06.html. Хотя исходные тексты открыты уже несколько лет и проблема коренится в использовании опасных функций работы со строками (strcat), отчет о ней появился только в 2000 году.
CVE–2002–0842, CVE–2003–0095, CAN–2003–0096
Из CVE–2002–0842:
Ошибка при работе с форматной строкой в одной модификации функции mod_dav, применяемой для протоколирования сообщений о плохом шлюзе (например, Oracle9i Application Server 9.0.2), позволяет удаленному противнику выполнить произвольный код, обратившись к URI, для которого сервер возвращает ответ «502 BadGateway». В результате функция dav_lookup_uri() в файле mod_dav.c возвращает спецификаторы форматной строки, которые потом используются при вызове ap_log_rerror().
Из CVE–2003–0095:
Переполнение буфера в программе ORACLE.EXE для Oracle Database Server 9i, 8i, 8.1.7 и 8.0.6 позволяет удаленному противнику выполнить произвольный код, задав при входе длинное имя пользователя. Ошибкой можно воспользоваться из клиентских приложений, самостоятельно выполняющих аутентификацию, что и продемонстрировано на примере LOADPSP.
Из CAN–2003–0096:
Многочисленные ошибки переполнения буфера в Oracle 9i Database Release 2, Release 1, 8i, 8.1.7 и 8.0.6 позволяют удаленному противнику выполнить произвольный код, (1) задав длинную строку преобразования в качестве аргумента функции TO_TIMESTAMP_TZ, (2) задав длинное название часового пояса в качестве аргумента функции TZ_OFFSET и (3) задав длинную строку в качестве аргумента DIRECTORY функции BFILENAME.
Эти ошибки документированы в бюллетене CERT СА–2003–05 по адресу www.cert.org/advisories/CA–2003–05.html. Их – в числе прочих – обнаружил Дэвид Литчфилд со своими сотрудниками из компании Next Generation Security Software Ltd. Попутно отметим, что не стоит объявлять свои приложения «не–взламываемыми», если за дело берется г–н Литчфилд.
CAN–2003–0352
Из описания в CVE:
Переполнение буфера в одном интерфейсе DCOM, используемом в системе RPC, применяемой в Microsoft Windows NT 4.0,2000, ХР и Server 2003, позволяет удаленному противнику выполнить произвольный код, сформировав некорректное сообщение. Этой ошибкой воспользовались черви Blaster/MSblast/LovSAN and Nachi/Welchia.
Это переполнение интересно тем, что привело к широкому распространению двух весьма разрушительных червей, что повлекло за собой глобальные неприятности в сети Интернет. Переполнялся буфер в куче, доказательством возможности эксплуатации ошибки стало появление очень стабильного червя. Ко всему прочему еще был нарушен принцип предоставления наименьших привилегий, этот интерфейс не должен был быть доступен анонимным пользователям. Интересно еще отметить, что предпринятые в Windows 2003 контрмеры свели последствия атаки к отказу от обслуживания вместо эскалации привилегий.
Подробнее об этой проблеме можно прочитать на страницах www.cert.org/ advisories/CA–2003–23.html и www.microsoft.com/technet/security/bulletin/MS03–039.asp.
Искупление греха
Путь к искуплению греха переполнения буфера долог и тернист. Мы обсудим несколько способов избежать этой ошибки, а также ряд приемов, позволяющих сократить ущерб от нее. Посмотрите, как можно улучшить свои программы.
Замена опасных функций работы со строками
Как минимум вы должны заменить небезопасные функции типа strcpy, strcat и sprintf их аналогами со счетчиком. Замену можно выбрать несколькими способами. Имейте в виду, что интерфейс старых вариантов функций со счетчиком оставляет желать лучшего, а кроме того, для задания параметров часто приходится заниматься арифметическими вычислениями. В грехе 3 вы увидите, что компьютеры не так хорошо справляются с математикой, как могло бы показаться. Из новых разработок стоит отметить функцию strsafe, Safe CRT (библиотеку времени исполнения для С), которая войдет в состав Microsoft Visual Studio (и очень скоро станет частью стандарта ANSI C/C++), и функции strlcat/strlcpy для *nix. Обращайте внимание на то, как каждая функция обрабатывает конец строки и усечение. Некоторые функции гарантируют, что строка будет завершаться нулем, но большинство старых функций со счетчиком таких гарантий не дают. Опыт группы разработки Microsoft Office по замене небезопасных функций работы со строками в Office 2003 показал, что коэффициент регресии (число новых ошибок в расчете на одно исправление) очень мал, так что пусть страх внести новые ошибки вас не останавливает.
Следите за выделениями памяти
Еще одна причина переполнения буфера – это арифметические ошибки. Прочитайте в грехе 3 о переполнении целых чисел и найдите в своем коде все места, где для вычисления размера буфера производятся арифметические вычисления.
Проверьте циклы и доступ к массивам
Переполнение возможно и в случае, когда неправильно проверяется условие выхода из цикла и не контролируется выход за границы массива перед записью в него. Это одна из самых трудных для обнаружения ошибок; вы увидите, что часто ошибка проявляется совсем не в том модуле, где была допущена.
Пользуйтесь строками в стиле С++, а не С
Это эффективнее простой замены стандартных С–функций, но может повлечь за собой кардинальную переработку кода, особенно если программа собиралась не компилятором С++. Вы должны хорошо представлять себе характеристики производительности STL–контейнеров. Вполне возможно написать очень эффективный код с использованием STL, но, как всегда, нежелание читать руководство (RTFM – Read The Fine Manual) может привести к коду, далекому от оптимального. Наиболее типичное усовершенствование такого рода – переход к использованию шаблонных классов std::string или std::wstring.
Пользуйтесь STL–контейнерами вместо статических массивов
Все вышеупомянутые проблемы относятся и к STL–контейнерам, например vector, но ситуация осложняется еще и тем, что не все реализации класса vector::iterator контролируют выход за границы контейнера. Указанная в заголовке мера может помочь, и автор полагает, что STL способствует быстрому написанию правильного кода, но имейте в виду, что это все же не панацея.
Пользуйтесь инструментами анализа
На рынке появляются прекрасные инструменты для анализа кода на языках C/C++ на предмет нарушения безопасности, в том числе Coverity, PREfast и Kloc–work. В разделе «Другие ресурсы» приведены ссылки. В состав Visual Studio .NET 2005 войдет программа PREfast и еще один инструмент анализа кода под названием Source code Annotation Language (SAL – язык аннотирования исходного текста), позволяющий обнаружить такие дефекты, как переполнение буфера. Проще всего проиллюстрировать SAL на примере. В показанном ниже фрагменте (примитивном) вы знаете, как соотносятся аргументы data и count: длина data составляет count байтов. Но компилятору об этом ничего не известно, он видит только типы char * and a size_t.
void *DoStuff(char *data, size_t count) {
static char buf[32];
return memcpy(buf, data, count);
}
На первый взгляд, код не содержит ничего плохого (если не считать, что мы возвращаем указатель на статический буфер, ну посмейтесь над нами). Однако если count больше 32, то возникает переполнение буфера. Если бы этот код был аннотирован с помощью SAL, то компилятор мог бы отловить эту ошибку:
void *DoStuff(__in_ecount(count) char *data, size_t count) {
static char buf[32];
return memcpy(buf, data, count);
}
Объясняется это тем, что теперь компилятор и/или PREfast знают о тесной связи аргументов data и count.
Дополнительные защитные меры
Дополнительные защитные меры – это как ремни безопасности в автомобиле. Часто они смягчают последствия столкновения, но в аварию попадать все равно не стоит. Важно понимать, что для всех основных способов минимизировать эффект от переполнения буфера условия, которые приводят к переполнению буфера, продолжают существовать, поэтому достаточно изощренная атака может обойти ваши контрмеры. Все же рассмотрим некоторые подходы.
Защита стека
Защиту стека первым применил Криспин Коуэн в своей программе Stack–guard, затем она была независимо реализована Microsoft с помощью флага компилятора /GS. В самом простом варианте суть ее состоит в том, что в стек между локальными переменными и адресом возврата записывается некое значение. В более современных реализациях для повышения эффективности может также изменяться порядок переменных. Достоинство этого подхода в том, что он легко реализуется и почти не снижает производительности, а кроме того, облегчает отладку в случае порчи стека. Другой пример – это программа ProPolice, созданная компанией IBM как расширение компилятора Gnu Compiler Collection (GCC). Любой современный продукт должен включать в себя защиту стека.
Запрет исполнения в стеке и куче
Эта контрмера существенно усложняет задачу хакера, но может сказаться на совместимости. Некоторые приложения считают допустимым компилировать и исполнять код на лету. Например, это относится к языкам Java и С#. Важно также отметить, что если противник сумеет заставить ваше приложение пасть жертвой атаки с возвратом в libc, когда для достижения неблаговидных целей выполняется вызов стандартной функции, то он сможет снять защиту со страницы памяти.
К сожалению, современная аппаратура по большей части не поддерживает эту возможность, а имеющаяся подержка зависит от процессора, операционной системы и даже ее конкретной версии. Поэтому рассчитывать на наличие такой защиты в реальных условиях не стоит, но все равно следует протестировать свою программу и убедиться, что она будет работать, когда стек и куча защищены от исполнения. Для этого нужно запустить ее на том процессоре и операционной системе, которые поддерживают аппаратную защиту. Например, если целевой платформой является Windows ХР, то прогоните тесты на машине с процессором AMD Athlon 64 FX под управлением Windows ХР SP2. В Windows эта технология называется Data Execution Protection (DEP – защита от исполнения данных), а раньше носила имя No eXecute (NX).
ОС Windows Server 2003 SP1 также поддерживает эту возможность, равно как подсистема РаХ для Linux и OpenBSD.
Другие ресурсы
Writing Secure Code, Second Edition by Michael Howard and David C. LeBlanc (Microsoft Press, 2002), Chapter 5, «Public Enemy #1: Buffer Overruns»
«Defeating the Stack Based Buffer Overflow Prevention Mechanism of Microsoft Windows Server 2003» by David Litchfield: www.ngssoftware.com/papers/ defeating–w2k3–stack–protection.pdf
«Non–stack Based Exploitation of Buffer Overrun Vulnerabilities on Windows NT/2000/ХР» by David Litchfield: www.ngssoftware.com/papers/non–stack–bo–windows.pdf
«Blind Exploitation of Stack Overflow Vulnerabilities» by Peter Winter–Smith: www.ngssoftware.com/papers/NISR.BlindExploitation.pdf
«Creating Arbitrary Shellcode In Unicode Expanded Strings: The 'Venetian' Exploit» by Chris Anley: www.ngssoftware.com/papers/unicodebo.pdf
«Smashing The Stack For Fun And Profit» by Alephl (Elias Levy): www.insecure.org/stf/smashstack.txt
«The Tao of Windows Buffer Overflow» by Dildog: www.cultdeadcow.com/ cDc_files/cDc–351/
Microsoft Security Bulletin MS04–011/Security Update for Microsoft Windows (835732): www.microsoft.com/technet/security/Bulletin/MS04–011 .mspx
Microsoft Application Compatibility Analyzer: www.microsoft.com/windows/ appcompatibility/analyzer.mspx
Using the Strsafe.h Functions: http://msdn.microsoft.com/library/en–us/winui/ winui/windowsuserinterface/resources/strings/usingstrsafefunctions.asp
More Secure Buffer Function Calls: AUTOMATICALLY!: http://blogs.msdn.com/michael_howard /archive/2005/2/3.aspx
Repel Attacks on Your Code with the Visual Studio 2005 Safe С and С++ Libraries: http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCand С / default.aspx
«strlcpy and strlcat – Consistent, Safe, String Copy and Concatenation by Todd C. Miller and Theo de Raadt: www.usenix.org/events/usenix99/millert.html
GCC extension for protecting applications from stack–smashing attacks: www.trl. ibm.com/projects/security/ssp/
PaX: http://pax.grsecurity.net/
OpenBSD Security: www.openbsd.org/security.html
Static Source Code Analysis Tools for C: http://spinroot.com/static/
Резюме
Рекомендуется
Тщательно проверяйте любой доступ к буферу за счет использования безопасных функций для работы со строками и областями памяти.
Пользуйтесь встраиваемыми в компилятор средствами защиты, например флагом /GS и программой ProPolice.
Применяйте механизмы защиты от переполнения буфера на уровне операционной системы, например DEP и РаХ.
Уясните, какие данны контролирует противник, и обрабатывайте их безопасным образом.
Не рекомендуется
Не думайте, что компилятор и ОС все сделают за вас, это всего лишь дополнительные средства защиты.
Не используйте небезопасные функции в новых программах.
Стоит подумать
Об установке последней версии компилятора C/C++, поскольку разработчики включают в генерируемый код новые механизмы защиты.
О постепенном удалении небезопасных функций из старых программ.
Об использовании строк и контейнерных классов из библиотеки С++ вместо применения низкоуровневых функций С для работы со строками.
Грех 2.
Ошибки, связанные с форматной строкой
В чем состоит грех
С форматной строкой связан новый класс атак, появившихся в последние годы. Одно из первых сообщений на эту тему прислал Ламагра Аграмал (Lamagra Arga–mal) 23 июня 2000 года (www.securityfocus.com/archive/1/66842). Месяцем позже Паскаль Бушарен (Pascal Bouchareine) дал более развернутое пояснение (www.securityfocus.eom/archive/l/70552). В более раннем сообщении Марка Слемко (Mark Slemko) (www.securityfocus.com/archive/1 /10383) были описаны основные признаки ошибки, но о возможности записывать в память речи не было.
Читать бесплатно другие книги:
