Продолжение статьи       -     Перейти вначало статьи >>

Проверка целостности кода

Вредоносное программное обеспечение, реализованное в виде драйвера устройства режима ядра, включая программы захвата прав администратора, работает с использованием того же уровня привилегий, что и ядро, и поэтому его выявление и удаление является наиболее сложной задачей. Такие программы могут изменять поведение ядра и других драйверов таким образом, что становятся практически неуловимыми. Компонент Windows Vista, обеспечивающий целостность кода режима ядра, известный также под названием подписывания кода режима ядра (KMCS), допускает загрузку драйверов устройств только в том случае, если они опубликованы и снабжены цифровой подписью разработчиков, проверенных одним из нескольких центров сертификации (CA). По умолчанию компонент KMCS обязательно присутствует в 64-разрядных версиях Windows Vista.

Поскольку центры сертификации берут плату за свои услуги и выполняют основные проверки происхождения кода, такие как проверка подлинности предприятия, довольно сложно создать анонимное вредоносное программное обеспечение, работающее в режиме ядра в 64-разрядной версии Windows Vista. Более того, вредоносная программа, которой удается пройти процедуру проверки, может, в принципе, оставить следы, ведущие к ее автору, в случае ее обнаружения в поврежденной системе. У компонента KMCS есть дополнительные применения, такие как предоставление информации группе Майкрософт, занимающейся интерактивным анализом сбоя, в случае возникновения подозрения о том, что драйвер содержит ошибку, вызывающую сбои пользовательских систем и разблокирование мультимедийного содержимого высокой четкости. Эти применения будут кратко описаны.

В компоненте KMCS используются технологии шифрования с открытым ключом, применявшиеся более десяти лет в операционной системе Windows и требующие, чтобы в коде режима ядра содержалась цифровая подпись, созданная одним из доверенных центров сертификации. Если издатель передает драйвер в лабораторию Майкрософт, проверяющую качество оборудования Windows (WHQL), и драйвер проходит проверку надежности, тогда Майкрософт выступает в качестве центра сертификации, подписывающего код. Большинство издателей получают подписи с помощью WHQL, но если в драйвере нет тестовой программы WHQL, издатель не хочет проходить проверку WHQL или драйвер является драйвером этапа первоначальной загрузки, загружающимся на начальном этапе запуска системы, издатели могут подписывать код самостоятельно. Для этого им требуется сначала получить сертификат подписывания кода от одного из центров сертификации, которые Майкрософт признает доверенными для подписания кода режима ядра. После этого автор выполняет цифровое хэширование кода, подписывает хэш, шифруя его с помощью закрытого ключа, и предоставляет сертификат и зашифрованный хэш вместе с кодом.

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

Windows выполняет также проверку соответствующих цепочек сертификатов вплоть до одной из служб выдачи корневых сертификатов, встроенных в загрузчик Windows и ядро операционной системы. Попытки загрузить неподписанный 64-разрядный драйвер невозможны в рабочей системе, поскольку в отличие от диспетчера Plug and Play, отображающего диалоговое окно с предупреждением, когда ему передается команда загрузить драйвер, не имеющий подписи, подтверждающей, что драйвер проходил проверку WQHL, 64-разрядная версия Windows Vista, каждый раз, когда она блокирует загрузку неподписанного драйвера, безмолвно записывает событие в журнал событий приложения проверки целостности кода, аналогичное показанному на рис. 5. 32-разрядная версия Windows Vista также проверяет подписи драйверов, но допускает загрузку неподписанных драйверов. Их блокирование привело бы к нарушению модернизированных систем Windows XP, которым требуются драйверы, которые были загружены в Windows XP, а также допускает поддержку оборудования, для которого существуют только драйверы Windows XP. Однако при выполнении загрузки неподписанного драйвера 32-разрядная версия Windows Vista также записывает события в журнал событий целостности кода.

Поскольку подписывание кода обычно используется для пометки кода в качестве версии, прошедшей тщательную официальную проверку, издатели, как правило, не стремятся подписывать тестовый код. Поэтому в Windows Vista включен режим тестового подписывания, который можно включать и отключать с помощью инструмента Bcdedit (описан в моей статье в мартовском выпуске TechNet Magazine за 2007 г.) и в рамках которого выполняется загрузка драйверов режима ядра, имеющих цифровую подпись, сделанную тестовым сертификатом, созданным собственным центром сертификации компании. Этот режим предназначен для использования программистами во время разработки кода. Когда операционная система Windows находится в этом режиме, на рабочем столе отображаются маркеры, подобные показанным на рис. 6.

Рис. 6 Режим тестового подписывания в операционной системе Windows Vista

Защищенные процессы

Мультимедийное содержимое следующего поколения, такое как HD-DVD, BluRay и другие форматы, имеющие лицензию AACS (Advanced Access Content System), получат широкое распространение в течение ближайших нескольких лет. В Windows Vista используется ряд технологий под общим названием Protected Media Path (PMP), которые требуются стандартом AACS для воспроизведения такого содержимого. К технологиям PMP относятся PUMA (Protected User-Mode Audio) и PVP (Protected Video Path), совместное использование которых обеспечивает для аудио и видео драйверов, а также для приложений медиа-проигрывателей, механизмы, предотвращающие запись содержимого в формате высокой четкости несанкционированными программами или аппаратурой.

PUMA и PVP определяют интерфейсы и специальную поддержку для аудио и видео проигрывателей, драйверов устройств и оборудования, но PMP, кроме этого, основывается на общем механизме ядра, реализованном в Windows Vista, называемом защищенным процессом. В основе защищенных процессов лежит стандартная конструкция Windows, инкапсулирующая выполняющийся исполняемый образ, его библиотеки DLL, контекст безопасности (учетная запись, в рамках которой работает процесс, и ее привилегии безопасности) и потоки, выполняющие код в рамках процесса, но запрещающие определенные типы доступа.

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

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

Более того, для предотвращения повреждений извне весь исполняемый код, загруженный в защищенный процесс, включая его исполняемый образ и библиотеки DLL, должен быть подписан либо корпорацией Майкрософт (WHQL) с использованием флага защищенной среды (PE), либо, если это аудиокодек, он должен быть подписан разработчиком с использованием сертификата подписывания DRM, полученным от Майкрософт. Поскольку код режима ядра может получить полный доступ к любому процессу, включая защищенные, а 32-разрядная версия Windows допускает загрузку неподписанного кода режима ядра, ядро предоставляет интерфейс API для защищенных процессов. Этот интерфейс предназначен для выдачи запроса о «чистоте» среды режима ядра и использования результата для разблокирования высококачественного содержимого только в том случае, если среди загружаемого кода нет неподписанного.

Не существует интерфейсов API, предназначенных специально для идентификации защищенных процессов, но имеется возможность выполнить косвенную идентификацию, основываясь на имеющейся ограниченной информации об этих процессах и невозможности выполнять их отладку даже при использовании учетной записи с административными правами. Процесс изоляции графа аудиоустройств (%Systemroot%\System32\Audiodg.exe) используется для воспроизведения дисков DVD, закодированных с помощью CSS, и в окне диспетчера задач его можно идентифицировать как защищенный процесс, поскольку диспетчер задач не в состоянии получить его командную строку, виртуализацию и состояние предотвращения выполнения данных, даже если он запускается с правами администратора.

Рандомизация загрузки адресного пространства

Несмотря на такие меры, как предотвращение выполнения данных и усовершенствованная проверка ошибок компилятора, создатели вредоносного программного обеспечения продолжают находить уязвимости переполнения буфера, позволяющие им заражать процессы, ориентированные на работу в сети, такие как обозреватель Internet Explorer®, службы Windows и приложения сторонних разработчиков, с целью получения опорного пункта в системе. После удачного заражения процесса, однако, им необходимо использовать интерфейсы API Windows для выполнения своей конечной цели — чтения данных пользователя или обеспечения своего постоянного присутствия посредством изменения параметров пользовательской или системной настройки.

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

Компонент рандомизации загрузки адресного пространства (ASLR) в операционной системе Windows Vista лишает вредоносные программы возможности выяснить местоположение интерфейсов API. Это достигается за счет того, что при каждой загрузке системы системные библиотеки DLL и исполняемые модули загружаются в новом месте. На раннем этапе процедуры первоначальной загрузки диспетчер памяти выбирает случайное смещение для загрузки образа DLL из одного из 256 адресов (выровненных на 64 кБ), имеющихся в области размером 16 МБ в верхней части адресного пространства пользовательского режима. Когда библиотеки DLL, в заголовке образа которых присутствует новый флаг динамического размещения, загружаются в процесс, диспетчер памяти размещает их в памяти начиная с адреса смещения загрузки образа и продолжает по направлению к меньшим адресам.

Исполняемые образы, в которых установлен данный флаг, проходят аналогичную процедуру загрузки в случайную точку, выровненную на 64 КБ, в области размером 16 МБ от базового адреса загрузки, хранящегося в заголовке их образа. Кроме того, если данная библиотека DLL или исполняемый образ снова загружается после того, как был выгружен всеми использовавшими его процессами, диспетчер памяти снова выбирает для загрузки случайное местоположение. На рис. 7 показан пример компоновки адресного пространства для 32-разрядной системы Windows Vista, включая области, из которых ASLR выбирает смещение для загрузки образа и адрес загрузки исполняемого образа.

Только образы, имеющие флаг динамического размещения, к которым относятся все библиотеки DLL операционной системы Windows Vista и исполняемые образы, можно размещать в новых местах, потому что перемещение устаревших образов может привести к нарушению внутренних допущений о месте загрузки образов, сделанных разработчиками. В пакете обновления Visual Studio® 2005 SP1 добавлена поддержка для установки этого флага, чтобы сторонние разработчики могли воспользоваться преимуществами механизма ASLR в полной мере.

Назначение адресов загрузки библиотек DLL, выбираемых случайным образом из 256 местоположений, не лишает вредоносные программы возможности угадывать правильное местоположение интерфейса API, но оно резко снижает скорость распространения сетевого червя и препятствует надежной работе вредоносной программы, получающей только один шанс в инфицированной системе. Кроме того, у стратегии ASLR по изменению местоположения есть дополнительное преимущество, заключающееся в том, что адресные пространства используются более эффективно, чем в предыдущих версиях Windows — создаются обширные участки свободной памяти для распределения памяти смежными областями, уменьшается число таблиц страниц, выделяемых диспетчером памяти для отслеживания компоновки адресного пространства, и минимизируются несовпадения в буфере TLB.

Повышение безопасности служб

Службы Windows являются идеальными целями для атак со стороны вредоносного программного обеспечения. Многие из них для расширения функциональных возможностей предлагают доступ в сеть, тем самым увеличивая уязвимость при удаленном доступе к системе. Большая часть служб выполняется с более высоким уровнем привилегий, чем у стандартных учетных записей пользователей, что дает шанс повысить уровень привилегий в локальной системе, если они будут затронуты вредоносным программным обеспечением. По этой причине в Windows расширялись изменения, сделанные в пакете обновления Windows XP SP2 и направленные на снижение назначаемого службам уровня привилегий и доступа до уровня, необходимого для выполнения их ролей. Например, в пакете обновления 2 для Windows XP введены учетные записи локальной службы и сетевой службы, содержащие только подмножество тех привилегий, которые были доступны учетной записи локальной системы, в рамках которой эти службы выполнялись ранее. Это сводит к минимуму права доступа, получаемые злоумышленником, использующим службу.

Влияние, оказываемое ASLR, легко оценить путем сравнения адресов загрузки библиотеки DLL для процесса в двух разных сеансах загрузки с помощью такого средства, как Process Explorer от Sysinternals (обозреватель процессов). На этих двух снимках экрана, сделанных в двух разных сеансах, сначала библиотека Ntdll.dll загружалась в проводник по адресу 0x77A30000, а затем по адресу 0x77750000.

Отличающиеся базовые адреса для библиотеки ntdll.dll

Отличающиеся базовые адреса для библиотеки ntdll.dll 

В моей предыдущей статье было описано, как службы выполняются в их собственных сеансах изолированно от учетных записей пользователей, но в Windows Vista расширено также применение принципа наименьшего уровня привилегий путем дальнейшего уменьшения уровня привилегий и доступа к файлам, разделам реестра и портам брандмауэра, назначаемого большинству служб. В Windows Vista определена новая учетная запись группы, названная идентификатором безопасности службы (SID), уникальная для каждой службы. Служба может устанавливать разрешения на своих ресурсах, чтобы доступ к ним имелся только для идентификатора SID их службы, предотвращая, в случае компрометации службы, получение доступа другими службами, работающими в рамках этой же учетной записи. Идентификатор SID службы можно просмотреть, воспользовавшись командой sc showsid с указанием имени службы, как показано на рис. 8.

Идентификаторы SID служб защищают доступ к ресурсам, принадлежащим конкретной службе, но по умолчанию у служб имеется еще доступ ко всем объектам, к которым имеет доступ учетная запись пользователя, в рамках которой они работают. Например, служба, работающая в рамках учетной записи локальной службы, может не иметь доступа к ресурсам, созданным другой службой, работающей в качестве локальной службы в другом процессе, защищающем свои объекты с помощью разрешений, ссылающихся на идентификатор SID службы. Однако она по-прежнему может читать и записывать любые объекты, для доступа к которым имеет разрешения локальная служба (и любые группы, к которым принадлежит локальная служба, такие как группа «Служба»).

Поэтому в Windows Vista введен новый ограниченный тип службы, названный службой с ограничениями на запись, который разрешает службе доступ для записи только к объектам, доступным ее идентификатору SID, группе «Все» и идентификатору SID, назначенному сеансу работы. Для реализации этого подхода в системе используются ограниченные идентификаторы SID — тип SID, введенный ранее в Windows 2000. Если процесс, открывающий объект, является службой с ограничениями на запись, алгоритм проверки доступа изменяется таким образом, чтобы SID, который не был назначен процессу ни в ограниченной форме, ни в форме без ограничений, не мог использоваться для предоставления процессу доступа к объекту для записи. Следующая команда дает возможность выяснить, есть ли у службы ограничения:

sc qsidtype [service]

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

Следующее усовершенствование модели безопасности служб в операционной системе Windows Vista позволяет разработчику службы при регистрации службы в системе точно указать, какие привилегии безопасности необходимы службе для работы. Например, если службе необходимо создавать события аудита, в список включается привилегия «Аудит».

Когда диспетчер управления службами запускает процесс, работающий с одной или несколькими службами Windows, он создает маркер безопасности (объект ядра, формирующий список, в который входят учетная запись пользователя процесса, членство в группах и привилегии безопасности) для процесса, содержащего только привилегии, необходимые службам данного процесса. Если служба указывает привилегию, которая недоступна учетной записи, в рамках которой она работает, то служба не сможет запуститься. Если, например, ни одной из служб, работающих в рамках процесса с учетной записью локальной службы, не требуется привилегия программ отладки, диспетчер управления службами снимает эту привилегию с маркера безопасности процесса. Соответственно, если процесс службы скомпрометирован, вредоносный код не может воспользоваться преимуществами привилегий, которые не были явным образом запрошены службами, работающими в рамках процесса. Команда sc qprivs служит для формирования отчета о привилегиях, запрошенных службой.

Заключение

На этом завершается состоящий из трех частей обзор изменений, внесенных в ядро операционной системы Windows Vista. Некоторые компоненты и усовершенствования не были рассмотрены или упомянуты, например, новый рабочий пул потоков для разработчиков приложений, новые механизмы синхронизации, такие как общие блокировки средств чтения и записи, разметка потоков служб, поддержка интерактивной проверки диска NTFS и изменение объема том, а также новый механизм IPC ядра, названный ALPC. Для получения дополнительных сведений об этих и других компонентах см. следующее издание Windows Internals (Внутренняя структура Windows), публикация которого запланирована до конца 2007 г.

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

svchost -k LocalServiceNoNetwork

К службам, настроенным для работы в рамках этого процесса, относятся служба базовой фильтрации, служба политики диагностики, брандмауэр Windows, журналы и оповещения производительности и Windows Media® Center Service Starter.

На этом экране показан текстовый формат идентификатора SID службы базовой фильтрации, NT SERVICE\BFE, представленный один раз с флагом Restricted, и еще раз без него, поэтому у процесса есть доступ к ресурсам, доступ к которым имеется в рамках этой учетной записи. Однако у него не обязательно имеется доступ к другим объектам, доступным, как правило, для учетной записи локальной службы. Например, поскольку учетная запись NT AUTHORITY\SERVICE не представлена в маркере процесса с флагом ограничений, процесс не может изменять объекты, предоставляющие доступ для записи только этой учетной записи, но не другим учетным записям в маркере, имеющим флаг ограничений.

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

Флаги SID для службы