Использование технологий повышения информационной безопасности независимыми разработчиками

Привет, это Майкл,

В течение последних нескольких недель Мэтт Миллер (Matt Miller), Мэтт Томлинсон (Matt Thomlinson), Джон Лэмберт (John Lambert) и я работали над статьей, посвященной защите от атак, связанных с переполнением буфера, в операционных системах начиная с Windows Vista и Windows Server 2008. Хочу представить нашего нового блоггера, Мэтта Миллера, участника нашей команды исследователей в области информационной безопасности и разработки методов защиты от компьютерных атак (Security Research and Defense), написавшего отличную заметку, материалы которой легли в основу нашей совместной статьи.

Пожалуйста, Мэтт…

В блоге группы исследователей в области информационной безопасности и разработки методов защиты от компьютерных атак мы уже писали о преимуществах применения таких технологий снижения рисков, связанных с информационной безопасностью, как предотвращения выполнения команд из раздела данных (Data Execution Prevention – DEP) и использование случайным образом организованного адресного пространства (Address Space Layout Randomization – ASLR) [1,2]. Данные технологии наряду с такими как SEHOP, GS и т.д. созданы для того чтобы затруднить использование уязвимостей программного обеспечения. Популярность этих технологий привела к повышенному интересу сообщества исследователей в области информационной безопасности относительно разработки новых методов обхода защитных технологий [3]. Отслеживая новые результаты в этом направлении, мы продолжаем работу над повышением эффективности технологий снижения рисков информационной безопасности. Тем временем, независимые разработчики (Independent Software Vendors – ISV) могут быть уверены, что данные технологии максимально эффективны в текущей ситуации.

На практике, эффективность таких технологий снижения рисков информационной безопасности как DEP и ASLR в значительной мере зависит от того, насколько эта технология внедрена в процесс создания приложения. Неспособность полностью реализовать технологию снижения рисков в приложении делает его легкой добычей при осуществлении атаки с помощью эксплойта. В июне 2010 года Secunia распространила результаты исследования, в которых приводилась оценка применения независимыми разработчиками DEP и ASLR [4]. Исследование показало, что большинство из вошедших в исследование приложений не в полной мере используют преимущества этих технологий, что формирует почву для новых атак с помощью незакрытых уязвимостей.

В качестве примера можно рассмотреть эксплойт, который был написан для Adobe Reader’а (CVE-2010-2883), где основной уязвимостью была подключаемая библиотека DLL, в которой использование ASLR не было включено по умолчанию. Компания Adobe выполнила огромную работу по внедрению таких технологий, как ASLR, в большинстве используемых компонентов, но фактически наличие всего одной DLL с отключенным механизмом ASLR достаточно для появления серьезной уязвимости. Это справедливо и для других приложений, например, плагинов для Internet Explorer (Browser Helper Object – BHO) и объектов управления ActiveX с отключенным по умолчанию ASLR, которые в совокупности с какой-нибудь другой уязвимостью обозревателя Интернет могут позволить обойти систему защиты, основанную на ASLR. Эти примеры показывают, что внедрять технологии снижения рисков информационной безопасности нужно на 100%.

Как проверить настройки ASLR в приложении

Существует два основных способа проверить установки ASLR в приложении. Первый из них заключается в проверке того, что во всех запущенных в настоящий момент модулях EXE и DLL подключено использование ASLR. Посмотреть это можно с помощью утилиты Process Explorer с подключенной панелью для просмотра используемых библиотек DLL, где добавлен столбец «ASLR enabled» (ASLR подключен). На рисунке показан пример использования Process Explorer’а для обнаружения библиотеки jp2ssv.dll, в которой по умолчанию не используется ASLR, подключенной к Internet Explorer (значение столбца ASLR в соответствующей строчке пустое).

Process Explorer очень удобно использовать для получении информации о загруженных в текущий момент библиотеках DLL, но он не помогает определить библиотеки без ASLR, которые загружаются приложением в другое время. Эту информацию можно получить с помощью двоичного анализатора Microsoft BinScope. BinScope проверяет DLL и EXE файлы на диске на наличие специального флага (DYNAMICBASE), который должен быть установлен для использования ASLR. Далее приведен пример отчета создаваемого BinScope для библиотеки DLL с отключенным ASLR (nondynamicbase.dll) и библиотеки DLL, использующей эту технологию (dynamicbase.dll).

Советы независимым разработчикам

Для того чтобы помочь независимым разработчикам полностью использовать преимущества технологий обеспечения информационной безопасности, поддерживаемых Windows, мы опубликовали обновленный вариант руководства, которое объясняет как подключить такие технологии как DEP, ASLR и GS. Ознакомиться с руководством можно здесь:

https://msdn.microsoft.com/en-us/library/bb430720.aspx

Мы рекомендуем независимым разработчикам следовать руководству и, вообще говоря, мы включили его в Security Development Lifecycle (SDL). Также советуем обращаться по вопросам, связанным с внедрением технологий снижения рисков информационной безопасности, по адресу switech@microsoft.com.

Мэтт Миллер, MSEC Security Science

Оригинал статьи

Comments

• Anonymous
  April 19, 2011
  Я обнаружил две ошибки в антивирусе от Microsoft. первая ошибка позволяет удалить антивирус из системы с помощью моего собственного вируса,а вторая его отключить и имитировать его работу через вирус. у меня все работало отлично,а антивирус огорчил. я готов помочь в исправлении данных ошибок и указать их соотвественно. Мой адрес: HACKER-VOLK@yandex.ru

• Anonymous
  April 22, 2011
  The comment has been removed