Атаки, основанные на переполнении буфера, долгое время вызывали множество проблем и до сих пор являются одной из главных задач обеспечения безопасности в компьютерной индустрии. Первой атакой, основанной на переполнении буфера и распространяемой через Internet, стал червь Morris, нанесший серьезный ущерб в 1988 году. Особенно досадно, что создатели червя написали его из благих побуждений, а именно — для измерения масштабов Internet. Червь Morris взламывал несложные пароли и использовал известные уязвимые места программ для UNIX-платформ, таких как sendmail и Finger. Последние известные атаки, использующие переполнение буфера, черви CodeRed и SQL Slammer, перевели множество подключенных к Internet систем под управление хакеров. В 2001 году червь CodeRed взломал с помощью переполнения буфера сервер Microsoft Internet Information Services (IIS) 5.0 (версию Web-сервера IIS, поставляемую с системой Windows 2000), а в 2003 году червь SQL Slammer с помощью переполнения буфера проник на системы с установленным сервером баз данных Microsoft SQL Server 2000.
Можно противостоять атакам, использующим переполнение буфера, с помощью защитных механизмов, добавленных компанией Microsoft в системы Windows Vista и Windows Server 2008: Data Execution Prevention (DEP) и Address Space Layout Randomization (ASLR). Далее я объясню, почему эти механизмы так важны, и покажу, как выполняется их настройка и мониторинг.
Механизм переполнения буфера
Прежде чем более подробно рассматривать защитные механизмы систем Vista и Server 2008, стоит разобраться в процессе переполнения буфера и в том, каким рискам он подвергает ваши системы и данные.
Переполнение буфера возникает, когда вредоносная или просто плохо составленная программа сохраняет данные в память компьютера, превышая фиксированный размер буфера для данных. В результате такого переполнения данные перезаписывают соседние фрагменты памяти. Перезаписываемые данные могут содержать другие буферы, переменные, программную логику, которые искажают выходные результаты или приводят к аварийному завершению процесса. Еще большую угрозу представляют случаи, когда внедряемые данные содержат исполняемый код, который в итоге вынуждена выполнить атакованная программа. Этот код часто содержит основные механизмы атак, использующих переполнение буфера. Он используется для кражи или удаления данных, инициации отказов служб на основе состояния Denial of Service (DoS), изменения привилегий или распространения вредоносных программ на другие системы.
На рисунке приведен простой пример переполнения буфера. Программа определяет две переменные, которые сохраняются в соседних фрагментах памяти. Первая переменная — строка X длиной в 8 байт, вторая — целое число Y, размером 2 байт. Изначально строка X содержит только символы «0», а переменная Y — число 30. Представьте, что пользователь (случайно или умышленно) вводит строку OVERFLOW в эту программу. Программа пытается сохранить эту строку в память по адресу переменной Х и в конце записывает символ «0», чтобы обозначить конец строки. Алгоритм программы не проверяет длину строки и частично перезаписывает значение переменной Y. В результате, хотя программист не собирался менять значение Y, при вводе данных в переменную X значение переменной Y меняется с 30 на число, определяемое символом из строки, записываемой в память по адресу переменной X.
Разработчики могут избежать переполнения буфера, включив в код программы необходимые проверки на ограничения или применяя компиляторы и службы, работающие с активными процессами, для выполнения таких проверок. Проверки ограничений отслеживают объем вводимых данных. Хотя проверки ограничений и соответствующие принудительные меры доказали свою эффективность, множество существующих программ не содержат алгоритмов проверки ограничений. Кроме того, лучшие методики бесполезны, если некоторые программисты не следуют им.
Это объясняет, почему многие разработчики аппаратных средств, приложений и операционных системы, в том числе Microsoft, разработали проактивные механизмы защиты, которые пытаются предотвратить развитие атак на основе переполнения буфера в некорректно написанном коде. Давайте познакомимся с механизмами DEP и ASLR, разработанными компанией Microsoft.
Защита исполняемых данных
Как упоминалось выше, атаки, основанные на переполнении буфера, часто прописывают вредоносный исполняемый код в буферы памяти других приложений, после чего вынуждают приложения выполнять разрушающие систему действия. Вы можете прервать исполнение внедренного кода с помощью технологии DEP. Она позволяет системе Windows помечать те сегменты памяти, которые должны только хранить данные, как «неисполняемые» (NX). Если приложение пытается выполнить код из сегмента памяти с меткой NX, механизм DEP запретит это действие.
Обратная сторона медали при использовании механизма защиты от переполнений буфера DEP состоит в том, что блокировка приложения приводит к его аварийной остановке. Другими словами, хотя DEP не дает приложению исполнить вредоносный код, данная ситуация предоставляет хакерам возможность выполнить атаки, реализующие отказ в обслуживании, DoS.
Компания Microsoft добавила поддержку DEP не только в системы Vista и Server 2008, но и в пакеты Windows XP SP2, Windows Server 2003 SP1 и Windows 2003 R2. Механизм DEP реализован компанией Microsoft в двух вариантах: аппаратном и программном.
Аппаратная реализация службы DEP. Аппаратная реализация DEP использует функцию процессора, которую в AMD называют защитой неисполняемых страниц (NX), а в Intel — использованием запрещающего бита (XD). На момент написания статьи компания AMD поддерживает функцию NX только в 64-разрядных процессорах, а Intel поддерживает функцию XD только в модельном ряду 64-разрядных машин Itanium и EM64 T, а также в некоторых 32-разрядных моделях процессоров Prescott. Компания Microsoft — не единственный поставщик операционных систем, применяющий процессорные функции NX и XD для защиты от переполнения буфера: программное обеспечение, использующее функции NX и XD, поддерживается и в других операционных системах, таких как Linux и UNIX BSD (дополнительную информацию можно найти по адресу en.wikipedia.org/wiki/Nx-bit).
Программная реализация службы DEP. Программная реализация DEP позволяет компании Microsoft предоставлять данную технологию пользователям 32-разрядных систем, не оборудованных процессором с функциями NX или XD. При использовании данного продукта возможности процессорных функций NX и XD реализуются с помощью множества специальных указателей, автоматически добавляемых операционной системой Windows для объектов, хранящихся в системной памяти.
Поддерживает ли ваша система аппаратную реализацию службы DEP, легко проверить, просмотрев настройки DEP. Чтобы просмотреть эти настройки, щелкните на ярлыке Advanced Settings в окне System панели управления Control Panel и выберите в открывшемся окне Advanced and Performance Settings.
В нижней части окна настроек конфигурации службы DEP указан тип реализации данной службы, поддерживаемый вашей системой. На экране 1 отображено окно настроек DEP в системе Vista. Об остальных параметрах конфигурации я расскажу далее. Внизу экрана читаем: Your computer’s processor supports hardware-based DEP.
Если ваша система поддерживает программную реализацию службы DEP (т. е. процессор компьютера не поддерживает функции NX или XD), вы увидите сообщение Your computer’s processor does not support hardware-based DEP. However, Windows can use DEP software to help prevent some types of attacks.
Другой способ проверить, поддерживает ли ваша система аппаратную или программную реализацию службы DEP, — задействовать команды из инструментария Windows Management Instrumentation (WMI). Эта процедура описана в статье Microsoft, опубликованной по адресу support.microsoft.com/kb/912923.
В системах XP SP2, Windows 2003 SP1 и более поздних системах Microsoft технология DEP активирована по умолчанию. Однако механизмы DEP не всегда защищают все программы, работающие в системе. Точный список программ, защищаемых службой DEP, определяется уровнем защиты. Служба DEP поддерживает два уровня защиты:
-
Level 1. Первый уровень защищает только системный и исполняемый код платформы Windows и не распространяет механизм защиты DEP на остальные приложения компании Microsoft или независимых производителей;
-
Level 2. Второй уровень защищает весь исполняемый код в системе. Механизмы DEP применяются и к системному коду Windows, и к приложениям компании или независимых производителей.
По умолчанию системы XP SP2 и Vista запускают службу DEP на первом уровне защиты, системы Windows Server 2003 SP1 и Windows Server 2008 — на втором.
Администраторы могут настраивать уровни защиты посредством конфигурационного экрана службы DEP, показанного на экране 2. В этом примере (изображающем настройку службы DEP «по умолчанию» в системе Vista) механизмы DEP активированы только для важнейших программ и служб системы Windows — первый уровень защиты. Для переключения службы DEP на уровень 2 можно использовать переключатель Turn on DEP for all programs and services except those I select. По умолчанию данный режим устанавливается в системах Windows Server 2003 SP1 и Windows Server 2008.
Второй уровень защиты позволяет освободить определенные приложения от действия защитного механизма DEP. Эта возможность необходима, так как некоторые устаревшие приложения при включенном механизме DEP работают некорректно: например, в момент записи Microsoft Word автоматически освобождается от действия механизма DEP. Перед переключением на второй уровень защиты службы DEP требуется запустить для всех приложений тест совместимости и убедиться, что все приложения при включенном механизме DEP работают корректно. Чтобы освободить одно из приложений от действия DEP, можно добавить исполняемый файл приложения в список исключений на экране настройки с помощью кнопки Add.
Вы можете проверить, защищено ли данное приложение механизмом DEP, просмотрев столбец DEP в приложении Windows Task Manager для процесса, порожденного этим приложением (см. экран 2). Если столбец DEP в системе не отображается, можно добавить его с помощью пункта View, Select Columns службы Task Manager.
Освободить приложения от действия механизма DEP можно и другим способом — создать программную модификацию, распространяемую по вашим системам, которая будет автоматически отключать механизм DEP для выбранных в них приложений. В качестве примера компания Microsoft приводит такую программную модификацию, как слой DisableNX. Для создания этой модификации следует ознакомиться с инструментарием Microsoft Application Compatibility Toolkit (ACT), который, помимо прочего, включает в себя полезную в данном вопросе программу Compatibility Administrator (technet.microsoft.com/en-us/windowsvista/aa905078.aspx). Разработчики приложений могут применить и обратный подход — прописать поддержку механизма DEP в исполняемом коде приложений. Для этого они при компиляции используют параметр/NXCompat.
И наконец, одно немаловажное замечание: если активирован второй уровень защиты механизма DEP, система будет работать немного медленнее, так как все дополнительные проверки проводятся на уровне процессора и системной памяти. Поэтому для систем, не имеющих доступа в Internet, стоит рассмотреть возможность полного отключения механизма DEP. Единственный способ отключить службу DEP в системе — добавить параметр/NoExecute=AlwaysOff в системный файл boot.ini.
Имейте в виду, что вы можете использовать тот же параметр/NoExecute= с другими значениями для активации механизма DEP и установки уровня защиты. В табл. 1 приведены все значения параметра/NoExecute.
Файл boot.ini доступен только в системах XP и Windows 2003, и вы можете редактировать его с помощью приложения Notepad или раздела Startup and Recovery в свойствах системы.
В системах Vista и Server 2008 файл boot.ini заменен на файл Boot Configuration Data (BCD). Для редактирования файла BCD компания Microsoft предоставляет утилиту командной строки bcdedit.exe.
При запуске приложения bcdedit без параметров оно отображает текущую загрузочную конфигурацию. На экране 3 приведен результат действия приложения bcdedit в системе Vista. Обратите внимание на последнюю строку, содержащую конфигурацию механизма NX OptIn. Для перевода механизма NX в состояние «выключен всегда» нужно выполнить следующую команду:
bcdedit/set nx alwaysoff
Значения, приведенные в табл. 1 для параметра/NoExecute= файла boot.ini, также могут быть использованы в параметре nx файла BCD.
Дополнительную информацию о механизме Microsoft DEP и методах его настройки можно найти в статье компании Microsoft по адресу support.microsoft.com/kb/875352/en-us.
Рандомизация размещения адресного пространства
Другой технологией, часто используемой при атаках, построенных на основе переполнения буфера, является внедрение в буфер приложения указателя, ссылающегося на точку размещения важной библиотеки DLL в системной памяти. После этого вирус обманом заставляет программу вызвать данный системный файл, что позволяет ему задействовать службы данной библиотеки без риска быть обнаруженным.
Этот тип атаки относительно легко провести, если операционная система всегда загружает определенные библиотеки в одни и те же сегменты памяти. Например, в системе XP точки размещения системных библиотек не меняются — они незначительно отличаются только в зависимости от установленной версии пакета обновлений. Новая служба ASLR в системах Vista и Server 2008 усложняет использование служб из системных библиотек путем рандомизации точек размещения библиотек DLL в памяти. В отличие от механизма DEP, служба ASLR в ранних версиях Windows недоступна.
Каждый раз при перезапуске систем Windows Vista и Windows Server 2008 служба ASLR случайно привязывает системный код (обычно системные библиотеки DLL и исполняемый код) к определенным точкам в системе. Это означает, что точки начала системного кода (адреса, используемые вирусом для вызова службы) невозможно определить заранее. В системах Windows Vista и Windows Server 2008 библиотеки DLL или исполняемый код могут быть загружены в любой из 256 регистров. Это означает, что хакер имеет шанс 1 к 256 на получение нужного адреса. Служба ASLR также усложняет хакерам процесс написания рекурсивного кода, например червей, целью которого являются идентичные ресурсы на нескольких машинах.
Вы можете увидеть эффект работы механизмов ASLR с помощью службы SysInternals, загрузить которую можно по адресу www.microsoft.com/technet/sysinternals/utilities/processexplorer.mspx. Для использования данного средства запустите службу Process Explorer и убедитесь, что в меню View отмечен параметр Show Lower Pane.
После этого выберите процесс explorer.exe в верхнем окне и зафиксируйте базовый адрес библиотеки ntdll.dll в столбце base нижнего окна. Если вы не видите столбец base, то можете добавить его с помощью пункта меню View, Select Columns — столбец Base добавляется из вкладки DLL.
Запишите базовый адрес и перезагрузите компьютер. В системе XP базовый адрес библиотеки ntdll.dll остается неизменным после перезагрузки (система XP не поддерживает технологию ASLR). В системе Vista после перезагрузки базовый адрес меняется (так как система Vista поддерживает технологию ASLR).
На экране 4 изображен интерфейс Process Explorer и базовый адрес библиотеки ntdll.dll. В табл. 2 приведены базовые адреса библиотек ntdll.dll и user32.dll, зафиксированные при запуске Process Explorer в системах XP SP2 и Vista.
Механизм ASLR можно использовать не только для рандомизации точек размещения в памяти системных файлов Windows, но и для рандомизации точек размещения исполняемого кода и библиотек DLL для любых приложений, работающих в системах Vista или Windows Server 2008. Для этого разработчики приложений должны провести компиляцию кода с использованием указателя/dynamicbase. Инструментарий Microsoft Visual Studio поддерживает такую возможность начиная с версии Visual Studio 2005 SP1.
Как и механизм DEP, ASLR не является разработкой исключительно компании Microsoft. Механизмы ASLR были реализованы задолго до появления систем Vista и Windows Server 2008, на таких платформах, как Linux и UNIX. Кроме того, определенные решения Host Intrusion Detection System (HIDS) поддерживали технологию ASLR в линейке систем Windows задолго до того, как системы Windows получили ее встроенную поддержку.
Подробный анализ использования Microsoft ASLR в системе Vista приведен в статье компании Symantec по адресу: www.symantec.com/avcenter/reference/Address_Space_Layout_Randomization.pdf. В отличие от службы DEP, компания Microsoft не предлагает специализированного шаблона настройки для оптимального использования технологий ASLR.
Основные механизмы проактивной защиты
Механизмы проактивной защиты от переполнения буфера, предлагаемые технологиями ASLR и DEP, несколько отличаются друг от друга. В то время как служба ASLR усложняет поиск вирусом нужного кода, механизм DEP не дает вирусу выполнить код по найденному адресу. Обе технологии можно применять одновременно, а также использовать их в виртуальных системах, таких как продукты семейств Microsoft Virtual PC и VMware.
С точки зрения поддержки приложений важно помнить, что необходимо тестировать приложения на совместимость с механизмом DEP, прежде чем использовать их в системах с активированной службой DEP. Действие механизма DEP может привести к нарушению работы некоторых приложений или даже к их аварийному завершению.
Важно понимать, что службы DEP и ASLR не решают проблемы переполнения буфера. Обе технологии мешают вирусам использовать эту лазейку в своих целях. Например, служба ASLR усложняет процесс поиска системного кода вирусом, но не в состоянии его предотвратить. В большинстве случаев службы ASLR и DEP эффективно противостоят атакам, основанным на переполнении буфера.
Жан де Клерк (jan.declerq@hp.com) — член Security Office корпорации HP. Специализируется на проблемах управления идентичностью и вопросах безопасности продуктов Microsoft
Рисунок. Простой пример работы механизма переполнения буфера
Экран 3. Пример работы bcdedit в Windows Vista
Таблица 1. Значения параметра NoExecute= в boot.ini и пояснения
Таблица 2. Воздействие ASLR на базовый адрес DLL