Подразделение Microsoft, занимающееся созданием безопасных продуктов (Secure Windows Initiative, SWI), вышло из тени и пообещало, что его работа станет более прозрачной. Были сообщены и некоторые подробности об уязвимостях в программах и о бюллетенях по вопросам безопасности.

SWI, задача которого заключается в поддержке всех этапов обязательного в Microsoft цикла обеспечения безопасности разработки (Security Development Lifecycle, SDL) и управлении ими, открыло новый блог. Посетив его, пользователи могут ознакомиться с техническими подробностями, касающимися “дыр” в системе безопасности, способами ограничения возможного ущерба и временными решениями для их латания.

Недавно Райан Нарейн, редактор eWeek Security Watch, встретился с Джонатаном Нессом, ведущим инженером по безопасности ПО. В беседе были затронуты вопросы о группе SWI Defense, методах составления рейтинга уязвимостей ПО, о том, что происходит после обнаружения бреши в системе безопасности, о плюсах и минусах сотрудничества со сторонними исследователями.

eWeek: Каков ваш жизненный путь? Как вы попали в Microsoft?

Джонатан Несс: В 2002 г. во время рождественских каникул я от корки до корки изучил второе издание книги старшего менеджера программы по безопасности в Microsoft Майкла Ховарда “Написание безопасного кода”.

В то время я работал в военной области и, прочитав строчку за строчкой все 600 страниц этой книги, сразу решил попытаться попасть в команду Ховарда. Я прошел собеседование и оказался здесь, в составе SWI. То есть все произошло из-за той книги.

eWeek: Каковы ваши функции в SWI?

Дж. Н.: Я член одной из нескольких независимых групп, которая именуется SWI Defense. Она занимается главным образом разработкой способов ограничения потенциального ущерба и решений для устранения уязвимостей.

Мы тесно сотрудничаем с центром реагирования на угрозы безопасности (Microsoft Security Response Center, MSRC) и c разработчиками продуктов. Вместе с ними мы воспроизводим уязвимости, создаем и тестируем временные решения, позволяющие их закрыть, и помогаем оценивать серьезность проблем безопасности.

“Если нам кажется, что информация может пригодиться для атаки, мы предпочитаем не раскрывать ее в нашем блоге”.

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

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

eWeek: Что происходит, когда об уязвимости сообщают независимые или работающие в других компаниях исследователи проблем безопасности?

Дж. Н.: Когда к нам поступает сообщение об ошибке, сотрудники MSRC знакомятся с ним и убеждаются, что у нас имеется вся необходимая информация для воспроизведения проблемы. Они заводят карточку, уведомляют исследователя и передают дело в группу SWI React. Если в MSRC считают его весьма важным, эта группа немедленно принимается за него вместе с MSRC и разработчиками соответствующего продукта.

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

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

eWeek: Независимые исследователи жалуются, что Microsoft перекладывает на них трудности, связанные с воспроизведением или проверкой наличия уязвимости...

Дж. Н.: Мы пытаемся воспроизвести любую уязвимость, о которой становится известно. Мы действительно стремимся собрать всю информацию, будь это просто уведомление по электронной почте или пример эксплойта. Мы изучаем код, создаем инструменты тестирования и прикладываем все усилия для обнаружения того, о чем сообщил исследователь. Если нам это не удается, остается только обратиться к исследователям и просить их о помощи в воспроизведении уязвимости.

"Мы стремимся воспроизвести каждую уязвимость, о которой становится известно, стараемся собрать о них всю возможную информацию…"

Когда представляется такая возможность, мы стараемся выделить компьютер и обращаемся к ним с просьбой произвести атаку, чтобы попытаться выявить уязвимость. Наша главная задача — воспроизвести ее, изучить и устранить проблему.

eWeek: И что происходит, когда уязвимость воспроизведена?

Дж. Н.: Основная цель моей группы — понять уязвимость, найти те места, где эксплойт может поразить уязвимый код, затем изучить способы уменьшения негативных последствий и найти временные решения, чтобы закрыть уязвимость.

В некоторых случаях, если проблема требует, чтобы до выхода исправления было опубликовано сообщение об имеющейся опасности, мы выпускаем средства, позволяющие уменьшить потенциальный ущерб. Это должно помочь пользователям понять, как они могут защититься, пока мы не подготовим исправление. Затем в очередной вторник (Patch Tuesday), когда будет издан бюллетень, вы сможете ознакомиться с результатами нашей работы в разделе, посвященном мерам по уменьшению негативных последствий.

В процессе изучения мы обнаруживаем вещи, которые не очень годятся для публикации в бюллетене. Поэтому мы решили открыть новый блог (blogs.technet.com/swi), где обсуждаем мельчайшие подробности отдельных уязвимостей. Здесь мы во всех деталях рассматриваем исправленные нами уязвимости, способы ограничения возможного ущерба и некоторые другие временные решения, которые, может быть, не обладают 100-процентной эффективностью, но тем не менее полезны для определенных пользователей.

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

Дж. Н.: Мы хотим быть уверены, что люди понимают, в чем заключаются уязвимости и какие имеются способы смягчить проблему. Конечно, хакеры тоже могут воспользоваться какой-то информацией, чтобы понять характер ошибки. Но следует помнить, что мы обсуждаем только те из них, которые уже исправлены.

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

Записи в нашем блоге, совпадая по времени с выпускаемыми Microsoft по вторникам исправлениями, будут содержать более подробную информацию по сравнению с разделом бюллетеня, посвященным способам ограничения потенциального ущерба. Мы надеемся, что это поможет прояснить вопросы, которые не освещаются в бюллетене.

“Если эксплойт находит уязвимый код, мы считаем, что хакер способен обойти ограничения”.

“Плохие парни” подвергают наши исправления обратному инжинирингу сразу после их выпуска. Мы знаем об этом, потому что подписались на коммерческие пакеты эксплойтов, нам известно, что происходит и какие исследования проводятся сторонними специалистами после выхода наших “заплаток”.

eWeek: Microsoft критикуют за то, что она слишком медленно готовит рекомендации и временные решения для уже известных хакерам уязвимостей, которые используются, пока не выпущены исправления. Это справедливо?

Дж. Н.: Рекомендации пользователям о необходимых действиях появляются, как только мы завершаем тестирование уязвимости и осознаем, с чем она связана. В начале некоторые проблемы могут носить весьма туманный характер, если речь идет о сложной уязвимости. Мы стремимся быстро воспроизвести ее и оценить связанный с нею риск. Иногда это удается сразу, иногда нет. Довольно сложно определить, сколько времени потребуется для подготовки рекомендаций.

eWeek: Майкл Ховард, гуру Microsoft в области безопасности, выдвинул тезис, согласно которому обнаруженные в Windows Vista уязвимости, связанные с переполнением буфера, не имеют большого значения, поскольку в этой операционной системе есть встроенный механизм резервного копирования. SWI будет заниматься подобными проблемами?

Дж. Н.: Майкл выдвинул правильный тезис, но пока мы не видим повода для смягчения критериев при оценке Vista.

Нам проблема видится следующим образом. Если эксплойт находит уязвимый код, мы считаем, что хакер способен обойти ограничения. Конечно, Vista может перехватить и прервать процесс, но в действительности эксплойт все-таки отыскивает уязвимый код. Вот как мы на это смотрим: если он достигает кода, то мы и оцениваем опасность соответствующим образом.

Даже когда Internet Explorer работает в защищенном режиме, имеются определенные способы запустить из него эксплойт. Мы должны учитывать такую возможность при определении степени опасности ошибок. То же самое относится и к другим механизмам Vista, ограничивающим потенциальный вред, например ASLR (Address Space Layout Randomization). Если эксплойт предпримет 256 попыток, из которых только одна окажется удачной, мы тем не менее будем считать систему уязвимой.

В некоторых случаях мы не столь строги в своих оценках систем вроде Windows Server 2003; там, где использование скриптов запрещено, мы снижаем рейтинг уязвимости сервера до “умеренного”. Но если присутствует подверженный опасности код и его можно взломать с помощью эксплойта, мы будем считать, что эксплойт сработал. И это отразится на рейтинге.

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

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

eWeek: Согласно принятой в Microsoft шкале ошибка оценивается как “критическая”, если ее можно использовать для распространения интернет-червя без каких-либо действий со стороны пользователя. Но в ваших бюллетенях, посвященных Internet Explorer, ошибка считается критической, даже если для успешной атаки пользователю необходимо щелкнуть по ссылке на веб-сайт...

Дж. Н.: Мы рассматриваем переход по ссылке в качестве ожидаемого действия пользователя. Фактически это означает: зайдешь на сайт, и ты попался. У нас это называется “уязвимостями нулевого щелчка” (zero-click vulnerabilities). Мы всегда относим их к категории критических, хотя в действительности применительно к ним нельзя говорить о проникновении червей.