До сих пор в этой серии освещались усовершенствования ядра Windows Vista, относящиеся к процессам, системе ввода и вывода, управлению памятью, запуску системы, завершению работы системы и управлению питанием. В данной третьей и последней
части будут рассмотрены компоненты и усовершенствования, относящиеся к вопросам надежности, восстановления и безопасности.
В компоненте управления учетными записями пользователей (UAC — User Account Control), который не рассматривается в этой серии, используется несколько разных технологий, включая виртуализацию файловой системы и реестра для устаревших приложений, согласие на повышение уровня для получения доступа к административным правам и механизм Windows® Integrity Level для изоляции процессов, работающих с административными правами, от процессов с низким уровнем привилегий, работающих в рамках одной и той же учетной записи. Подробное обсуждение структуры компонента UAC появится в будущем выпуске TechNet Magazine.
В операционной системе Windows Vista™ повышение надежности системы и расширение возможностей пользователя при диагностике неполадок системы и приложений достигается посредством ряда новых компонентов и усовершенствований. Например, модуль регистрации отслеживания событий ядра для Windows (ETW) всегда находится в активном состоянии, создавая в кольцевом буфере события отслеживания для операций с файлами, реестром, прерываний и операций других видов. При возникновении неполадки новая диагностическая инфраструктура Windows (WDI) делает моментальный снимок буфера и анализирует его локально или загружает в службу технической поддержки Майкрософт для поиска и устранения неполадки.
Новый монитор производительности и надежности позволяет пользователям соотносить ошибки, например, сбои и зависания, с изменениями, внесенными в настройку системы. Мощный инструмент восстановления системы (SRT) заменяет консоль восстановления для восстановления в автономном режиме систем, не подлежащих перезагрузке.
Три компонента основаны на изменениях системы, сделанных на уровне ядра, и поэтому они заслуживают более пристального рассмотрения в этой статье: диспетчер транзакций ядра (KTM), усовершенствованная обработка сбоев и поддержка предыдущих версий.
Диспетчер транзакций ядра
Одной из наиболее утомительных задач разработки программного обеспечения является обработка состояний ошибки. Это особенно верно, если в процессе выполнения операции высокого уровня приложение выполнило одну или несколько подзадач, приведших к изменениям файловой системы или реестра. Например, служба обновления прикладной программы может внести несколько изменений в реестр, заменить один из исполняемых модулей приложения, после чего ей может быть отказано в доступе при попытке обновить второй исполняемый модуль. Если в службе не предусмотрена возможность оставлять приложение в таком противоречивом состоянии, она должна отслеживать все вносимые изменения и иметь возможность их отменить. Проверка кода восстановления после ошибки является трудной задачей и, вследствие этого, часто опускается, поэтому ошибки в коде восстановления могут свести на нет все усилия.
Приложения, написанные для Windows Vista, при очень небольшой затрате усилий могут приобрести возможности автоматического восстановления после ошибок, используя для этого новую поддержку транзакций в NTFS и реестре, обеспечиваемую диспетчером транзакций ядра. Если приложению требуется выполнить ряд связанных изменений, оно может либо создать транзакцию координатора распределенных транзакций (DTC) и дескриптор транзакции KTM, либо напрямую создать дескриптор KTM и уставить связь между изменениями файлов и разделов реестра с транзакцией. В случае успешного завершения всех изменений приложение выполняет транзакцию, и изменения применяются, но в любой момент вплоть до этой точки приложение может выполнить откат транзакции, после чего изменения будут аннулированы.
Следующее преимущество состоит в том, что другие приложения не видят изменений, внесенных в транзакции, пока транзакция не будет завершена, а приложения, использующие DTC в Windows Vista и готовящийся к выпуску сервер Windows Server®, носящий кодовое название «Longhorn», могут координировать свои транзакции с помощью SQL Server™, сервера очереди сообщений Microsoft® (MSMQ) и других баз данных. Следовательно, служба обновления приложений, использующая транзакции KTM, никогда не оставит приложение в противоречивом состоянии. Именно поэтому как инструмент обновления Windows, так и инструмент восстановления системы используют транзакции.
Являясь основой поддержки транзакций, KTM обеспечивает диспетчерам транзакционных ресурсов, таких как NTFS и реестр, возможность координировать свои обновления в случае конкретного набора изменений, выполненных приложением. В Windows Vista файловая система NTFS использует для поддержки транзакций расширение TxF. Реестр использует аналогичное расширение с названием TxR. Эти диспетчеры ресурсов режима ядра работают совместно с KTM, координируя состояние транзакции, точно так же, как диспетчеры ресурсов пользовательского режима используют DTC для координации состояния транзакции в нескольких диспетчерах ресурсов пользовательского режима. Сторонние разработчики также могут использовать KTM для реализации своих собственных диспетчеров ресурсов.
Как TxF, так и TxR определяют новый набор интерфейсов файловой системы и реестров, аналогичных существующим, за исключением того, что в них включен параметр транзакции. Если приложению требуется создать файл в рамках транзакции, сначала используется KTM для создания транзакции, затем результирующая обработка транзакции передается интерфейсу API создания нового файла.
Как TxF, так и TxR основаны на быстро работающих функциях ведения журнала файловой системы, обеспечиваемых общей системой файлов журнала или системой CLFS (Common Log File System) (%SystemRoot%\System32\Clfs.sys), которая была введена в Windows Server 2003 R2. TxR и TxF используют CLFS для надежного хранения транзакционных изменений до завершения транзакции. Это позволяет им обеспечивать транзакционное восстановление и гарантии даже в случае сбоя в подаче питания. Кроме журнала CLFS расширение TxR создает набор связанных файлов журнала для отслеживания изменений в системном файле реестра в %Systemroot%\System32\Config\Txr, как показано на рис. 1, а также отдельные наборы файлов журналов для каждого пользовательского куста реестра. TxF хранит транзакционные данные для каждого тома в скрытом каталоге на томе с именем \$Extend\$RmMetadata.
Усовершенствованная поддержка при сбоях
В случае возникновения в Windows неустранимой ошибки режима ядра — из-за ошибок в драйвере устройства, сбоев оборудования или операционной системы — выполняется попытка предотвратить повреждение данных, хранящихся на диске, посредством остановки работы системы после отображения печально известного «синего экрана» и, если имеется соответствующая настройка, записи содержимого некоторого участка или всей физической памяти в файл аварийной копии памяти. Файлы аварийной копии памяти полезны, поскольку при перезагрузке после сбоя интерактивная служба Майкрософт для анализа сбоя (OCA — Online Crash Analysis) предлагает выполнить их анализ для поиска причины сбоя. При желании их можно проанализировать самостоятельно с помощью средств Майкрософт для отладки в Windows).
Однако в предыдущих версиях Windows поддержка файлов аварийной копии памяти оставалась не активированной до момента инициализации файлов страниц памяти процессом диспетчера сеанса (%Systemroot%\System32\Smss.exe). Это означало, что любые важные ошибки, возникавшие до этого момента, приводили к отображению синего экрана, а файл с копией памяти не создавался. Поскольку основная часть инициализации драйвера устройства происходит до запуска Smss.exe, сбои на раннем этапе никогда не сопровождаются аварийными копиями памяти, что крайне затрудняет выявление причин.
В Windows Vista период времени, в течение которого не создается файл копии памяти, сокращен благодаря инициализации поддержки файла копии памяти до загрузки драйверов этапа запуска системы, сразу после инициализации всех драйверов устройств, необходимых на этапе первоначальной загрузки. Вследствие этого изменения при возникновении сбоя на раннем этапе процесса первоначальной загрузки система может сделать аварийную копию памяти, наличие которой позволяет использовать OCA для разрешения возникшей проблемы. Кроме этого, Windows Vista сохраняет данные в файле копии памяти в виде блоков по 64 КБ, в то время как в предыдущей версии Windows файлы записывались с использованием блоков по 4 КБ. В результате этого изменения большие файлы копии памяти записываются в 10 раз быстрее.
В Windows Vista усовершенствована также обработка сбоев приложений. В предыдущих версиях Windows при возникновении сбоя приложения выполнялся обработчик необработанных исключений. Обработчик запускал процесс Майкрософт для создания сообщения об ошибках приложения (AER) (%Systemroot%\System32\Dwwin.exe), отображающий диалоговое окно с указанием программы, в которой возник сбой, и запросом об отправке сообщения об ошибке в Майкрософт. Однако, если во время сбоя повреждался стек основного потока процесса, при выполнении обработчика необработанных исключений возникал сбой, приводящий к завершению процесса ядром, мгновенному исчезновению окон программы и полному отсутствию диалогового окна с сообщением.
В Windows Vista обработка ошибок перемещена из контекста обработки сбоев в новую службу создания сообщений об ошибках Windows (WER). Эта служба реализуется посредством библиотеки DLL (%Systemroot%\System32\Wersvc.dll) в рамках процесса размещения службы. При возникновении сбоя приложения по-прежнему выполняется обработчик необработанных исключений, но обработчик отправляет сообщение службе WER, и служба запускает процесс создания сообщений об отказах WER (%Systemroot%\System32\Werfault.exe) для отображения диалогового окна с сообщением об ошибке. Если стек поврежден, и возникает сбой обработчика необработанных исключений, обработчик выполняется повторно и снова возникает сбой, то, в конце концов, исчерпывая весь стек потока (вспомогательная область памяти), и в этот момент вступает в игру ядро и отправляет службе сообщение с уведомлением о сбое.
Отличие этих двух подходов видны на рис. 2 и 3, где показана взаимосвязь процессов Accvio.exe, тестовой программы, в которой возник сбой, и процессов создания сообщений об ошибках, выделенных зеленым цветом, в операционных системах Windows XP и Windows Vista. Новая архитектура обработки ошибок в Windows Vista означает, что программы больше не будут молча заканчивать работу, не предлагая Майкрософт возможности получить сообщение об ошибке, и разработчики программного обеспечения смогут усовершенствовать свои приложения.
Теневое копирование тома
В Windows XP была внедрена технология теневого копирования тома для создания моментальных снимков томов дисков в конкретные моменты времени. Приложения резервного копирования используют эти моментальные снимки для создания непротиворечивых образов резервных копий, но моментальные снимки остаются все время скрытыми, за исключением периода работы процесса резервного копирования.
Эти моментальные снимки не являются, по существу, полными копиями томов. Скорее они представляют собой виды тома из некоторой предшествующей точки, содержащие оперативные данные тома, перекрытые копиями секторов тома, подвергавшихся изменениям с момента создания моментального снимка. Драйвер поставщика моментальных снимков томов (%Systemroot\%System32\Drivers\Volsnap.sys) контролирует операции, в которых участвуют тома, и, прежде чем разрешить изменение секторов, делает их резервные копии, сохраняя исходные данные в файле, связанном с моментальным снимком, в каталоге тома, содержащем системную информацию о томе.
В Windows Server 2003 администраторам предоставлялась возможность управлять моментальными снимками на сервере и пользователям — на клиентских системах посредством теневых копий общих папок. Эта функция обеспечивала постоянные моментальные снимки, доступ к которым пользователи получали с помощью вкладки «Предыдущие версии» из диалоговых окон свойств проводника для своих папок и файлов, находящихся на общих файловых ресурсах сервера.
Компонент «Предыдущие версии» операционной системы Windows Vista обеспечивает поддержку для всех клиентских систем, автоматически создавая моментальные снимки томов, как правило, один раз в день, доступ к которым можно получить из диалоговых окон свойств проводника с помощью того же интерфейса, который используется теневыми копиями общих папок. Это позволяет просматривать, восстанавливать и копировать старые версии файлов и каталогов, которые могли быть случайно изменены или удалены. Не являясь с технической точки зрения новой технологией, реализация теневого копирования томов в компоненте «Предыдущие версии» операционной системы Windows Vista оптимизирует аналогичную функцию, существовавшую в Windows Server 2003, для применения в клиентской рабочей среде.
В Windows Vista преимущества моментальных снимков томов используются также для того, чтобы объединить механизмы защиты пользовательских и системных данных и избежать сохранения избыточного объема данных резервного копирования. Если установка приложения или внесение изменений в конфигурацию приводят к неправильному или нежелательному поведению, можно воспользоваться средством восстановления системы — компонентом, введенным в линейку операционных систем Windows NT® в системе Windows XP, чтобы восстановить системные файлы до состояния, в котором они находились в момент создания точки восстановления.
В Windows XP средством восстановления системы используется драйвер фильтра системы файлов (драйвер этого типа различает изменения, сделанные на уровне файлов), чтобы резервные копии системных файлов создавались в момент их изменения. В операционной системе Windows Vista средством восстановления системы используются моментальные снимки томов. Если в операционной системе Windows Vista для возврата в точку восстановления применяется пользовательский интерфейс средства восстановления системы, то копирование предыдущих версий измененных системных файлов из моментального снимка, соответствующего данной точке восстановления, выполняется фактически на том, находящийся в рабочем режиме.
BitLocker
В настоящее время Windows Vista является наиболее защищенной версией среди операционных систем Windows. Помимо того, что в Windows Vista входит антишпионский модуль Windows Defender, в операционную систему интегрированы также многочисленные компоненты безопасности и глубокой защиты, включая средство шифрования всего тома BitLocker™, подписывание кода для кода режима ядра, защищенные процессы, рандомизация загрузки адресного пространства и усовершенствованные защита служб Windows и управление учетными записями пользователей.
Операционная система может применять свои политики безопасности, только когда она находится в активном состоянии, поэтому необходимо принять дополнительные меры для защиты данных в тех случаях, когда может быть нарушена физическая безопасность системы, и доступ к данным может быть получен, минуя операционную систему. Механизмы, основанные на использовании оборудования, например пароли BIOS и шифрование, являются технологиями, широко используемыми для предотвращения несанкционированного доступа, особенно на портативных компьютерах, вероятность потери или кражи которых наиболее высока.
В Windows 2000 была реализована шифрованная файловая система (EFS), и вариант EFS, реализованный в Windows Vista, содержит ряд усовершенствований по сравнению с предыдущими реализациями, включая повышение производительности, поддержку шифрования файла подкачки и хранение пользовательских ключей EFS на смарт-картах. Однако файловую систему EFS невозможно использовать для защиты доступа к уязвимым участкам системы, таким как файлы куста реестра. Например, если групповая политика допускает вход в систему портативного компьютера, даже если он не подключен к домену, то средства проверки учетных данных домена кэшируются в реестре, поэтому злоумышленник может воспользоваться программными инструментами для получения хэша пароля доменной учетной записи и использовать его для попытки получения пароля с помощью взломщика паролей. Пароль обеспечит злоумышленнику доступ к учетной записи и файлам EFS (в том случае, если ключ EFS не хранится на смарт-карте).
Для упрощения процедуры шифрования загрузочного тома (том, на котором находится каталог Windows), включая все его системные файлы и данные, в Windows Vista введен компонент шифрования диска Windows BitLocker, предназначенный для шифрования всего тома. В отличие от EFS, которая реализуется посредством драйвера файловой системы NTFS и работает на уровне файлов, BitLocker выполняет шифрование на уровне тома с помощью драйвера шифрования всего тома (FVE — Full Volume Encryption) (%Systemroot%\System32\Drivers\Fvevol.sys)
FVE представляет собой драйвер фильтра, поэтому он автоматически отслеживает все запросы операций ввода и вывода, которые система NTFS передает тому, шифруя блоки во время их записи и расшифровывая их во время чтения с помощью ключа шифрования всего тома (FVEK — Full Volume Encryption Key), назначенного тому во время его первоначальной настройки для использования компонента BitLocker. По умолчанию тома шифруются с использованием 128-разрядного ключа AES и 128-разрядного ключа рассеивателя. Поскольку шифрование и расшифровка выполняются на уровне системы ввода и вывода, находящейся ниже уровня системы NTFS, она воспринимает том как незашифрованный и не обязана знать о том, что компонент BitLocker активен. Однако при попытке чтения данных с тома без использования операционной системы Windows данные на томе выглядят как случайные.
Ключ FVEK шифруется с помощью главного ключа тома (VMK — Volume Master Key) и хранится на томе в области, специально отведенной для метаданных. При настройке компонента BitLocker предлагается ряд вариантов защиты ключа VMK, зависящих от возможностей оборудования системы. Если в системе имеется модуль доверенной платформы (TPM ), поддерживающий версию 1.2 спецификации TPM, и имеется соответствующая поддержка BIOS, ключ VMK может быть зашифрован либо с помощью TPM, когда система шифрует VMK с помощью ключа, хранящегося в TPM и ключа, хранящегося на флэш-устройстве USB, либо ключ может быть зашифрован с помощью ключа, хранящегося в TPM, и ПИН-кода, вводимого при загрузке системы. Для систем, в которых нет модуля TPM, BitLocker предлагает вариант шифрования ключа VMK с помощью ключа, хранящегося на внешнем флэш-устройстве USB. В любом случае необходим незашифрованный том емкостью 1,5 ГБ с системой NTFS, на котором хранятся диспетчер загрузки (Boot Manager) и база данных конфигурации загрузки (BCD).
Преимущество использования модуля TPM заключается в том, что в BitLocker используются функции TPM для гарантии того, что BitLocker не расшифрует ключ VMK и не разблокирует том, если BIOS или загрузочные файлы системы были изменены с момента активирования BitLocker. При первоначальном шифровании системного тома и при каждом обновлении любого из упомянутых компонентов BitLocker вычисляет хэши SHA-1 для этих компонентов и все хэши, называемые измерениями, сохраняет в разных регистрах конфигурации платформы (PCR) модуля TPM с помощью драйвера устройства TPM (%Systemroot%\System32\Drivers\Tpm.sys). Затем модуль TPM используется для запечатывания ключа VMK. При выполнении этой операции используется хранящийся в TPM закрытый ключ для шифрования VMK и значения, хранящиеся в регистрах PCR, наряду с другими данными, которые BitLocker передает модулю TPM. Затем BitLocker сохраняет запечатанный ключ VMK и зашифрованный ключ FVEK в области метаданных тома.
При загрузке системы она выполняет измерение своего собственного хэширования и кода загрузки PCR и записывает хэш в первый PCR модуля TPM. Затем она хэширует BIOS и сохраняет это измерение в соответствующем PCR. В свою очередь BIOS хэширует следующий компонент из последовательности начальной загрузки, основную загрузочную запись (MBR) загрузочного тома, и эта процедура продолжается до тех пор, пока не будет измерен загрузчик операционной системы. Каждый последующий фрагмент кода, который выполняется, отвечает за измерение загружаемого им кода и за сохранение измерения в соответствующем регистре модуля TPM. Наконец, когда пользователь выбирает загружаемую операционную систему, диспетчер загрузки (Bootmgr) считывает зашифрованный ключ VMK с тома и выдает модулю TPM запрос на его раскрытие. Только в том случае, когда все измерения совпадают с теми, которые были сделаны при запечатывании ключа VMK, включая дополнительный ПИН-код, TPM успешно расшифровывает ключ VMK.
Эту схему можно рассматривать как цепочку проверок, в которой каждый компонент последовательности начальной загрузки описывает следующий компонент модулю TPM. Модуль откроет свой секрет только в том случае, если все описания совпадут с теми, которые были исходно предоставлены модулю TPM. Таким образом, BitLocker защищает зашифрованные данные даже в том случае, если диск снят и перенесен в другую систему, если система загружается с использованием другой операционной системы или если на загрузочном томе скомпрометированы незашифрованные файлы.
Проверка целостности кода
Вредоносное программное обеспечение, реализованное в виде драйвера устройства режима ядра, включая программы захвата прав администратора, работает с использованием того же уровня привилегий, что и ядро, и поэтому его выявление и удаление является наиболее сложной задачей. Такие программы могут изменять поведение ядра и других драйверов таким образом, что становятся практически неуловимыми. Компонент 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 находится в этом режиме, на рабочем столе отображаются маркеры
Защищенные процессы
Мультимедийное содержимое следующего поколения, такое как 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 в действии
Влияние, оказываемое ASLR, легко оценить путем сравнения адресов загрузки библиотеки DLL для процесса в двух разных сеансах загрузки с помощью такого средства, как Process Explorer от Sysinternals (обозреватель процессов). На этих двух снимках экрана, сделанных в двух разных сеансах, сначала библиотека Ntdll.dll загружалась в проводник по адресу 0x77A30000, а затем по адресу 0x77750000.
В моей предыдущей статье было описано, как службы выполняются в их собственных сеансах изолированно от учетных записей пользователей, но в Windows Vista расширено также применение принципа наименьшего уровня привилегий путем дальнейшего уменьшения уровня привилегий и доступа к файлам, разделам реестра и портам брандмауэра, назначаемого большинству служб. В Windows Vista определена новая учетная запись группы, названная идентификатором безопасности службы (SID), уникальная для каждой службы. Служба может устанавливать разрешения на своих ресурсах, чтобы доступ к ним имелся только для идентификатора SID их службы, предотвращая, в случае компрометации службы, получение доступа другими службами, работающими в рамках этой же учетной записи. Идентификатор SID службы можно просмотреть, воспользовавшись командой sc showsid с указанием имени службы
Идентификаторы 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 не представлена в маркере процесса с флагом ограничений, процесс не может изменять объекты, предоставляющие доступ для записи только этой учетной записи, но не другим учетным записям в маркере, имеющим флаг ограничений.
Службы, выполняющиеся в этом процессе, также ограничивают свои привилегии, поскольку привилегии, перечисленные в нижней части диалогового окна свойств, являются подмножеством тех, которые доступны учетной записи локальной службы.
