Издательский дом ООО "Гейм Лэнд"ЖУРНАЛ ХАКЕР #121, ЯНВАРЬ 2009 г.

SDL, или безопасность по Microsoft. Беседуем с Иваном Медведевым о Security Development Lifecycle

Беседу ведет Степа Ильин




2003 год, 1.500.000 инфицированных компьютеров по всему миру, 3.370.000 звонков в службу поддержки, множество негатива в прессе – цена ошибки в двух строчках кода службы RPCSS. Что изменилось в подходе к разработке безопасного кода со времен «Бластера», как самим писать надежные приложения - это и многое другое рассказал нам Иван Медведев, Senior Development Lead компании Microsoft.

«Если бы пять лет назад Microsoft поехала с презентацией на BlackHat, большинство людей просто рассмеялось бы», -- признает наш гость. Сейчас же – это обычное явление. В Microsoft огромное число хороших специалистов по безопасности, настоящих профи, но заставить такую огромную машину работать безукоризненно очень сложно. Нельзя просто придти и сказать: «С завтрашнего дня все 50000 сотрудников, которые работают в Microsoft, станут специалистами по безопасности». Это нереально! Поэтому компания всерьез взялась за разработку некоторого набора практик, проверенных подходов и инструментальных средств, которые позволяют разрабатывать безопасный код. Именно благодаря этому появилось то, о чем мы сегодня и поговорим, -- SDL или Security Development Lifecycle.

Семь стадий SDL

Иван Медведев руководит отделом по разработке внутренних программных средств для проверки программного обеспечения. Он специально прилетел в Москву, чтобы представить свой доклад по SDL и моделированию угроз на конференции SEC(R)2008, а мы не упустили возможности пообщаться с ним лично. И вот что он нам рассказал.

SDL на русский проще перевести как «жизненный цикл безопасного программного обеспечения». По сути, это документация, которая описывает так называемые best practices – рекомендуемые практики того, как разрабатывать безопасные приложения, и какие инструменты необходимо использовать для проверки безопасности. Если говорить просто: есть ряд правил, которым нужно следовать, и набор инструментов, которые нужно использовать. SDL предполагает, что разработка обязательно должна пройти семь стадий: обучение, подготовка требований, дизайн, разработка, проверка, выпуск, поддержка. Так вот, на каждой стадии документация SDL описывает какие-то рекомендуемые практики, – каким образом разрабатываемый код получался безопасным. Например, на стадии дизайна рекомендуется делать моделирование угроз и анализ поверхности атаки (подробности – ниже). На стадии разработки проверяется, не используются ли в проекте запрещенные функции, а также проводится статический анализ кода. Стадия проверки включает в себя такие вещи, как пентест, динамическое тестирование кода, а также фаззинг – все ради того, чтобы выявить проблемы в безопасности!

Понятно, что со временем как сами подходы, так и используемые инструменты меняются и модернизируются, поэтому SDL – тоже не статический документ: внутри Microsoft он обновляется каждые шесть месяцев. Лично меня сильно порадовал гибкий подход компании к внесению изменений. Новые правила берутся не из головы со словами: «А давайте сделаем вот это, так будет лучше!» – вместо этого специальная группа прислушивается к отзывам разработчиков и анализирует актуальные проблемы и угрозы. Одним из источников данных для анализа является подразделение Microsoft Security Response, которое выпускает патчи для продуктов компании. Ребята из отдела, которым руководит Иван, изучают статистику выпущенных обновлений, и если в какой-то момент замечают, что появилось непропорционально большое количество ошибок переполнения буфера или, скажем, RPC, то начинают думать, как можно изменить и модернизировать SDL, чтобы подобных багов больше не было. Это могут быть какие-то новые проверки, совершенно новые инструментальные средства (которые специально разрабатываются) или, вообще, изменения в компиляторе. Приятно, что у ребят есть возможность влиять на то, как работает компания. Они могут сначала подойти к группе, которая занимается компилятором, и попросить реализовать для него новый свитч (опцию), чтобы устранить проблему или сигнализировать о ней еще во время компиляции, а потом сказать всем группам разработчиков, что использование этой опции отныне обязательно. Кстати говоря, ни один продукт MS, начиная с SQL Server 2005,, не выходил на рынок без полного соответствия требованиям SDL.

Как это использовать?

Напрашивается один простой вопрос: а как вообще использовать SDL? Внедрить его внутри компании и группы разработчиков? Видимо, я оказался далеко не первым, кто его задает :). В ноябре компания выпустила специальный мануал SDL Optimization Model, представляющий собой набор рекомендаций, а по сути, инструкцию о том, как внедрить SDL в отдельно взятой компании. Понятно, что в рамках одной статьи полностью раскрыть требования и рекомендации SDL не получится (зато по этой теме есть книжки), но чтобы понять, о чем идет речь, приведу несколько примеров из категории «лучшие практики».

Все проекты на C/С++ необходимо компилировать с флагом /GS (определение переполнения буфера на основе стека), а линковать с /SAFESEH (/SafeSEH) – одно из правил SDL. В этом случае будут использованы механизмы защиты памяти с целью предотвращения эксплуатация общих уязвимостей. Еще одно правило из «Best Pratices» - использовать флаг /NXCompat, чтобы проверить файл на совместимость со средствами предотвращения исполнения данных (DEP) (/NXCompat).
В ходе разработки обязательно использовать несколько утилит, в том числе – PREfast, FxCop, Application Verifier. Тулза для статического анализа кода PREfast является частью Visual Studio (начиная с версии 2005) и вызывается с помощью специальной опции компилятора - /analyze. К примеру, на следующий участок кода будет выдано предупреждение об использовании в цикле функции _alloca, что может быстро переполнить стек:

char *b;
do {
b = (char*)_alloca(9)
} while(1)

Также распространяющийся когда-то как отдельная утилита, а теперь ставший частью Visual Studio, FxCop представляет собой инструмент для анализа кода, проверяющий сборки с управляемым кодом на соответствие правилам разработки с применением .NET Framework (да и вообще, здравому смыслу). Статический анализ позволяет выявить проблемы безопасности, быстродействия и надежности.

Application Verifier представляет собой уже динамический анализатор для unmanaged-кода. Динамический подход подразумевает, что программа анализируется прямо во время ее выполнения. AppVerif отслеживает активность приложения и проверяет, не выполняет ли оно действий, опасных с точки зрения безопасности. Например, если исследуемая программа создаст объект без дескриптора безопасности или небезопасным образом передает параметры в API, то выдается предупреждение.

Большая работа по улучшению качества кода была сделана в самой Visual Studio. К примеру, IDE будет сильно ругаться, если ты попробуешь использовать опасные функции, например, strcpy. Рассмотрим фрагмент кода:

void func(char *p) {
char d[20];
strcpy(d,p);
// etc
}

Если *p содержит ненадежные данные, то в этом коде имеется уязвимость. Но компилятор сам может заменить вызов функции strcpy вызовом более безопасной функции, которая позволит ограничить объем копируемых данных в соответствии с размером буфера назначения (а размер буфера статичен и известен в момент компиляции). Visual C++ позволяет включить в файл заголовков stdafx.h следующую строку:

#define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES 1

Все, теперь компилятор заменит небезопасную функцию таким образом:

void func(char *p) {
char d[20];
strcpy_s(d,__countof(d), p);
// etc
}

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

Моделирование угроз

На скриншоте ты видишь диаграмму угроз для одного из приложений. Вообще, моделирование угроз – это один из основных элементов Microsoft SDL, можно даже сказать, святая святых всего SDL. Такие диаграммы легко рисуются на листе бумаге или на доске в офисе, но для этого нужно четко представлять себе правила их построения. На первых порах удобнее использовать специальные средства, которые выпускаются довольно давно, но до недавнего времени не отвечали всем современным требованиям. Во время беседы Иван рассказал, что при его непосредственном участии в ноябре компания выпустит совершенно новое средство для моделирования угроз – и вот оно перед нами. SDL Threat Modeling Tool совершенно свободно доступна на сайте Microsoft, и единственное, что нужно для ее запуска, - это установленная на компьютере программа Visio.

Программа программой, а как создавать диаграммы угроз? Хороший вопрос. Начать стоит с некоторой обзорной диаграммы, в которой должно быть несколько интеракторов (участников), один или два процесса, хотя бы одно хранилище и соединяющие эти элементы потоки данных. Такая диаграмма должна иллюстрировать основную функциональность приложения. Следующий важный этап заключается в установке границ доверия. Границы доверия пересекают потоки данных – это точки, в которые может вмешаться атакующий. Так, процессы, общающиеся по сети, всегда пересекают границу доверия.
Есть несколько правил, которые нужно проверить:

1. Не появляются ли данные из воздуха? Запомни: данные приходит из внешних итеракторов или хранилищ.

2. У всех ли данных есть пользователи?

3. Не перемещаются ли данные магическим образом? Они всегда идут через процессы!

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

Фаззинг

В MS достаточно много внутренних средств, которые пока не готовы, но со временем могут принести пользу, в том числе, для фаззинга. Первый серьезный фаззер был написан в компании четыре с половиной года назад, когда мало еще кто знал этот термин. Напомню, что фаззинг – это метод нахождения проблем в безопасности, основанный на подаче интересным образом манипулированных данных на вход программы: будь то API или ввод данных пользователей. Есть много его разновидностей, но, в целом, он считается наиболее эффективным средством выявления проблем безопасности (если смотреть на количество найденных им проблем).

Фаззинг разделяется на множество категорий. Есть файл-фаззинг, который фаззит файлы. Программа, которая читает файл, каким-то образом его разбирает на части и что-то с ними делает. Например, Word с doc-файлами, просмотрщик изображений – с JPEG. Если взять этот JPEG и интересным образом поменять биты, то может быть эта программа, которая разбирает, вылетит с проблемой переполнения буфера.

По-философски, фаззинг распределяется на генерацию и мутацию. Генерация – случайным образом придуманный набор байтов, который подсовывается тому же Word'у со словами: «Это на самом деле doc-файл, читай его». Мутация – изменения в хорошем файле. Преимущества и недостатки есть у каждого из подходов. Очевидно, что в таких вещах, как сетевые протоколы, имеет смысл применять подходы мутации, используемые Man-in-the-middle фаззерами.
Помимо этого фаззинг разделяется на:

  1. Глупый (dump) фаззинг – ничего не знает о структуре файлов. «Давай случайным образом вот этот битик флипим или сгенерируем случайный набор данных и пошлем его».
  2. Умный (smart) фаззинг – знает о структуре данных все. К примеру, ему известно, что в JPEG в таком-то месте хранится длина какого-то блока. Посмотрим, что будет, если мы его увеличим на один. Что получится? Или на максимальное значение, которое может содержаться в этом поле. Нужно грамотно описать формат.

Есть внутренние средства, о которых Иван не может рассказывать по причинам NDA. Но есть и публично доступные фаззеры: Майк Эддингтон, который плотно сотрудничает с Microsoft, создал фаззер Peach (в переводе – персик, http://peachfuzzer.com). Достаточно эффективный фаззер, который принимает peach pits («косточки от персика») – как раз те самые описания формата, о которых мы говорили. С его помощью можно фаззить что угодно: включая сетевые сервисы, RPC, COM/DCOM, SQL-хранимые процедуры и файлы. Помимо этого стоит обратить внимание на:

Зачем нужна SDL?

Очень просто! Это шанс для всех разработчиков писать безопасный код, не будучи экспертами в безопасности. И это не так уж сложно: при правильной поддержке и при наличии правильных инструментов.

Программы для SDL

Как уже было сказано, SDL - не просто набор методик, описывающих создание безопасного кода, но еще и утилиты, которые всячески помогают в этом программистам. Какими бы ни были убедительными наставления SDL, гораздо более практичными для программиста, естественно, являются именно программы.

Для статического анализа кода Microsoft предоставляет тулзы Microsoft Source Code Analyzer for SQL Injection и XSS Detect Beta. Последний подключается к Visual Studio как плагин и позволяет распознать XSS-уязвимости в создаваемых веб-приложениях.

Ошибки XSS могут быть выявлены и с помощью программ, работающих в качестве прокси: RATS—Rough Auditing Tool for Security (http://www.fortify.com/security-resources/rats.jsp) и ProxMon (http://www.fortify.com/security-resources/rats.jsp).

На уровне кода и фреймворка можно также воспользоваться следующими библиотеками:

Помимо этого интерес представляют:

  • SiteLock - позволяет разработчикам на ActiveX полностью ограничить доступ к заранее заданному списку доменов или лимитировать его по времени. Утилита относится к типу «Best Practices», то есть к рекомендуемым методикам;
  • Banned.h - файл-зоголовок, позволяющий избавиться в своих исподниках от функций, которые давно не рекомендуются к использованию и запрещены SDL.

Та самая ошибка

Ошибка, о которой идет речь в статье и которую, в итоге, эксплуатировал известный червь Blaster, была в следующем фрагменте кода:

WCHAR wszMachineName[N+1] {
WCHAR wszMachineName[N + 1];
…
LPSTR pwszServerName = wszMachineName;
while (*pwszPath != L'\\')
*pwszServerName++ = *pwszPath++;

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

INFO

Внутри Microsoft всегда используется более новая версия SDL (так, публично доступна сейчас версия 3.2, хотя MS «сидит» на 4.0). Это связано со многими причинами и в том числе с тем, что MS использует закрытые разработки, не готовые пока выпускаться в паблик.

DVD

На DVD ты найдешь некоторые из упомянутых инструментов.

Содержание