Windows 11 и обязательная цифровая подпись драйверов
Windows 11, самая популярная потребительская настольная операционная система в мире, безусловно, имеет свои недостатки. Несмотря на них, это наиболее проработанная версия ОС от Microsoft, даже с учетом спорных нововведений, из-за которых многие пользователи предпочитают оставаться на Windows 10 или переходить на Linux. Однако существует аспект, вызывающий давние споры — политика Microsoft, требующая наличия цифровой подписи у всех драйверов перед их загрузкой системой.
Драйвер — это низкоуровневый код, зачастую работающий в ядре операционной системы, который позволяет аппаратному или программному обеспечению взаимодействовать с Windows. Подписанный драйвер содержит криптографическую подпись от доверенного центра (например, сертификат самой Microsoft или уполномоченного ею удостоверяющего центра). Windows проверяет ее на подлинность и целостность перед запуском.
Механизм принудительной проверки подписи драйверов развивался десятилетиями, став обязательным «швейцаром» в системе. Это явление обладает двойственной природой: с одной стороны, оно значительно повышает безопасность, блокируя запуск вредоносного ПО на столь глубоком уровне, с другой — ограничивает контроль пользователя и требует соблюдения правил Microsoft. Подобная политика враждебна к свободе пользователя, но при этом очевидно полезна. Это одна из лучших функций безопасности Windows, существование которой по своей сути антипотребительское.
Что такое цифровые подписи драйверов?
Подпись драйверов является частью функции безопасности Code Integrity, представленной еще во времена Windows Vista и ставшей обязательной в версии 1607 Windows 10. Концепция проста: любой код, работающий в ядре Windows (так называемом «Кольце 0»), должен иметь действительную цифровую подпись от доверенного центра. Согласно официальной документации Microsoft, Code Integrity «повышает безопасность операционной системы за счет проверки целостности драйвера или системного файла каждый раз, когда он загружается в память». В 64-битных версиях Windows «драйверы режима ядра должны быть подписаны цифровой подписью». На практике это означает, что Windows отказывается загружать любой драйвер без подписи признанного сертификата.
Как и в других операционных системах, ядро (ntoskernel.exe, или ядро Windows NT) является центром ОС с наивысшими привилегиями, поэтому блокировка несанкционированного кода в этой области критически важна. Цифровые подписи гарантируют, что драйвер был опубликован идентифицированным разработчиком и не подвергался изменениям. Неподписанные или вредоносно измененные драйверы просто не устанавливаются при настройках по умолчанию, что защищает как обычных потребителей, так и компании.
Легальные производители оборудования и разработчики проходят процесс подписи, который в современных версиях Windows часто включает получение сертификата расширенной проверки (EV) и отправку драйвера на утверждение в Microsoft. Если код пытается выполниться в ядре без одобрения, пользователь видит ошибку: «Windows не удается проверить цифровую подпись драйверов, необходимых для этого устройства». Это предотвращает целый класс атак, при которых вредоносное ПО могло бы установить руткит или опасный драйвер для получения полного контроля над системой. На 64-битных системах загрузка драйвера — по сути, единственный поддерживаемый способ выполнения произвольного кода в ядре, что полностью исключено для неподписанных исполняемых файлов.
Привилегии администратора
Даже учетные записи с уровнем прав администратора не имеют исключений. Независимо от того, кто вы, вы не можете загрузить неподписанный драйвер в 64-битной Windows. Единственные способы обойти это — использовать опцию загрузки «Отключение обязательной проверки подписи драйверов» (которая сбрасывается при следующей перезагрузке) или использовать утилиту bcdedit для полного отключения проверок. Это предохранительный механизм, установленный Microsoft, который не должен преодолевать даже владелец компьютера.
Ужесточение требований с течением времени
Путь Microsoft к обязательным подписям начался в середине 2000-х годов на фоне растущей обеспокоенности из-за шпионского ПО, руткитов и стабильности ОС. Начиная с Windows 2000, существовала программа командной строки Driver Verifier, предназначенная для проверки драйверов на незаконные функции и обнаружения ошибок; позже, с выходом Windows XP, она получила графический интерфейс. В то время подписание драйверов существовало, но не было строго обязательным: групповая политика позволяла запретить установку вовсе, предупредить пользователя или разрешить установку молча. Ситуация изменилась с выходом 64-битных версий Windows.
Эволюция обязательной подписи драйверов в Windows
Начиная с Windows Vista (и частично в Windows XP x64 Edition, где допускалась самоподпись сертификатов), 64-битные системы Windows ввели обязательное требование подписи драйверов режима ядра. Это стало частью масштабной инициативы по обеспечению безопасности, включавшей технологию Kernel Patch Protection, неформально известную как PatchGuard.
Внедрение обязательной подписи в Vista x64 вызвало споры, однако Microsoft заявляла целью устранение целых классов вредоносного ПО и, согласно некоторым отчетам того времени, защиту DRM. Очевидно, что контроль за подписью драйверов отвечает интересам отрасли, но также это означало, что Microsoft получила возможность фактически принуждать компании оплачивать лицензии для распространения своих драйверов. В противном случае такие драйверы просто не устанавливались на большинство систем.
С тех пор требования стали жестче: Windows 10 версии 1607 закрепила обязательное требование аттестационной подписи всех драйверов со стороны Microsoft. Windows 11, требующая по умолчанию наличие UEFI Secure Boot и TPM, усилила акцент на доверии к процессу загрузки и драйверам. По сути, современная Windows имеет центральный орган (Microsoft), определяющий, какой низкоуровневый код имеет право на выполнение. Результатом стала защита, которую сложнее преодолеть атакующим, при этом Microsoft (и небольшое число вендоров сертификатов) стали «привратниками» платформы Windows.
Безопасность ядра и борьба с угрозами
Microsoft стремится защитить ядро любой ценой, даже если это ограничивает возможности обычных разработчиков. Обоснованность этого подхода очевидна: обязательная подпись драйверов значительно повысила уровень безопасности. Блокируя неподписанные драйверы, система серьезно затрудняет работу руткитов и вредоносного ПО уровня ядра, которые ранее могли скрываться от антивирусов. Если раньше сложное вредоносное ПО работало как драйвер для доступа к памяти или модификации глубоких слоев системы, то сегодня, не имея украденного или утекшего цифрового сертификата, оно не может загрузить свой драйвер в полностью обновленной 64-битной Windows. Если при загрузке обнаруживается неподписанный драйвер, система просто не запускается.
Античит-системы как бенефициары защиты
Современные античит-системы для онлайн-игр стали основными выгодоприобретателями требований по подписи драйверов. Разработчики продвинутых читов стремятся запустить свои программы в режиме ядра, чтобы избежать обнаружения античитами, работающими в режиме пользователя. Именно поэтому такие решения, как Easy-Anti Cheat, Faceit и Riot Vanguard, устанавливают собственные драйверы ядра. Эти системы работают с уровнем привилегий выше, чем у пользователя-администратора, контролируя систему на предмет читов, блокируя доступ к памяти игры и предотвращая вмешательство в её код. Поскольку Windows отклоняет любой драйвер без надлежащей подписи, разработчики читов не могут произвольно загружать собственный код ядра для обхода защиты.
Методы обхода и контратаки: от BYOVD до защиты DMA
В ответ разработчики читов и вредоносного ПО ищут лазейки, что лишь доказывает эффективность контроля драйверов. Распространенный метод — BYOVD (Bring Your Own Vulnerable Driver), при котором атакующие находят уже подписанный, но уязвимый драйвер. Легитимный драйвер загружается системой, после чего через его уязвимости выполняется вредоносный код в ядре. Примером может служить использование драйвера Lenovo Mapper для развертывания неподписанного чит-драйвера и отключения проверки TPM, выполняемой Riot Vanguard.
Аналогичные проблемы касаются атак и читов на основе прямого доступа к памяти (DMA). DMA позволяет аппаратным устройствам обращаться к системной памяти напрямую, минуя CPU. Однако Windows использует Kernel DMA Protection с применением IOMMU для блокировки несанкционированных устройств PCIe. Доступ получают только устройства с драйверами, поддерживающими DMA Remapping, и эта функция также защищена механизмом подписи Microsoft. В сочетании с Secure Boot, блокирующим загрузчики читов еще до старта Windows, и аттестацией загрузки на основе TPM, создается значительно более безопасная среда, даже с учетом того, что это пользовательский ПК.
Уязвимости драйверов и вопросы контроля над системой
Существует множество примеров использования программ-вымогателей, злоупотребляющих драйверами для отключения функций безопасности системы и загрузки вредоносного кода непосредственно в ядро. По сути, это переносит вектор атаки с операционной системы на низкоуровневый код, который был проверен и подписан самой Microsoft. Разработчикам вредоносного ПО необходимо использовать уже установленный на компьютере пользователя драйвер, что вынуждает их либо находить уязвимости в крайне распространенных драйверах, либо обманом заставлять пользователя установить ПО, содержащее такую уязвимость.
Механизм принудительной проверки цифровых подписей драйверов является лишь одним из элементов общей архитектуры безопасности, и сам по себе он не способен предотвратить все угрозы. Тем не менее, в сочетании с другими технологиями Microsoft этот подход значительно повышает уровень защиты. Украденный сертификат неизбежно будет обнаружен и отозван, а аппаратные обходные пути часто оказываются недолговечными.
Почему принудительная проверка подписей драйверов вызывает критику?
Вопрос сводится к тому, что именно пользователь может запускать на собственном оборудовании. Критика заключается в том, что данный механизм безопасности ограничивает свободу пользователя и контроль над его системой. Между безопасностью и открытостью существует неявный компромисс, и Microsoft делает решительный выбор в пользу первого. Компания выбрала модель, при которой операционная система доверяет только низкоуровневому коду, одобренному Microsoft, что централизует власть и одновременно соответствует интересам индустрии, принося доход за счет сертификации.
Разработка собственного драйвера для личного использования, будь то для вашего собственного оборудования или для устройства, которое вы приобрели, сопряжена с трудностями. Пользователю необходимо либо загружаться с опцией «Отключение обязательной проверки подписи драйверов», полностью деактивируя проверки целостности, либо включать режим тестовой подписи Windows, что крайне неудобно. В итоге пользователь не владеет компьютером в привычном смысле слова — на уровне ядра контроль остается за Microsoft.
Кроме того, соответствовать требованиям к подписи драйверов могут только крупные компании или хорошо обеспеченные разработчики. Для того чтобы правильно подписать драйвер для современной версии Windows, разработчик должен получить сертификат EV Code Signing, что требует строгой проверки личности, наличия аппаратного токена и ежегодной оплаты в размере нескольких сотен долларов. Известный пример — текстовый редактор Notepad++, где программа уровня пользователя пострадала из-за отказа платить ежегодный взнос Microsoft за сертификацию. Та же концепция применима и к драйверам.
Последствия для владельцев старого оборудования и энтузиастов
Требования Microsoft могут препятствовать использованию старого оборудования, которое не получило обновлений с подписанными драйверами. Например, если вы попытаетесь подключить периферийное устройство эпохи Windows XP к компьютеру с Windows 11, драйвер которого не имеет цифровой подписи, система его заблокирует. Пользователю придется либо отключать проверку подписей (со всеми вытекающими рисками), либо отказаться от использования оборудования.
Хотя в прошлом модификация драйверов была возможна, сегодня решения класса «сделай сам» практически не встречаются из-за сложности и сопутствующих затрат. Более того, даже попытки сообщества взять ситуацию в свои руки могут привести к негативным последствиям. Существуют два известных драйвера, которые разработчики используют для управления вентиляторами системы: InpOut32 и WinRing0. Первый конфликтует с античитом Riot Vanguard, поэтому многие перешли на второй, ставший основой для таких инструментов, как Fan Control. Однако в 2020 году у WinRing0 была обнаружена критическая уязвимость, и спустя несколько лет Windows Defender начал блокировать этот драйвер, из-за чего все зависящие от него приложения перестали работать.
Проблема усугубляется стоимостью разработки и поддержки валидного драйвера. Тимоти Сан, основатель SignalRGB, отмечает сложность ситуации: «Поскольку WinRing0 устанавливается на уровне всей системы, мы осознали зависимость от той версии, которая была установлена первой. Это крайне затрудняло проверку того, не установили ли другие приложения потенциально уязвимые версии, что фактически подвергало пользователей риску, несмотря на все наши усилия». В 2023 году компания отказалась от WinRing0 в пользу проприетарного драйвера SMBus. Но, как подчеркивают разработчики, включая Сана, это дорогостоящее мероприятие. «Я не буду приукрашивать: процесс разработки был сложным и потребовал значительных инженерных ресурсов, — говорит Сан. — У небольших open-source проектов нет ни финансовых возможностей, ни опыта разработки для ядра Windows, чтобы пойти по такому пути», — добавляет Адам Хонс из OpenRGB.
Судьба WingRing0 и политика Microsoft
Разработчик WingRing0, компания OpenLibSys, в настоящее время проявляет минимальную активность. Маловероятно, что данный драйвер, даже в случае обновления, смог бы пройти процедуру одобрения Microsoft, учитывая ужесточение правил сертификации со стороны корпорации. Впрочем, Microsoft осознавала масштабы зависимости от этого драйвера — его использовали такие продукты, как Razer Synapse и SteelSeries Engine, — поэтому предоставила ему еще несколько лет жизни, прежде чем окончательно вывести из эксплуатации в 2025 году.
Linux: иная философия безопасности
В отличие от Windows, Linux представляет собой открытую систему, в которой нет единого центрального органа, диктующего правила работы кода в ядре. Дистрибутивы Linux способны обеспечить проверку подписей модулей — особенно при включенном режиме Secure Boot, когда некоторые системы требуют наличия ключа для модулей ядра. Однако в конечном итоге пользователь всегда может самостоятельно пересобрать ядро или отключить подобные проверки. Именно поэтому античит-системы в привычном для Windows виде не могут быть реализованы на Linux.
Уязвимость перед root-доступом
В Linux злоумышленник, обладающий правами root, наделен безграничными возможностями. Он может пересобрать ядро, удалив хуки античита, или загрузить собственный модуль ядра, не опираясь на централизованный центр сертификации. Учитывая, что многие читеры использовали метод запуска стороннего кода от имени суперпользователя в директории /root как достаточный способ избежать обнаружения, становится понятно, почему разработчики игр неохотно портируют античит-ПО на данную платформу.
Более того, даже если бы игра требовала обязательного root-доступа — что, вероятно, было бы опаснее, чем аналогичные решения в Windows, — пользователь мог бы запустить её в среде «fakeroot». В этой ситуации игра «думала» бы, что обладает правами администратора, не имея их на самом деле. Открытая природа Linux означает, что любая защитная мера может быть нейтрализована атакующим с аналогичным уровнем привилегий, и эта реальность отражается на текущем состоянии игрового сектора Linux. Несмотря на то что многие популярные проекты отлично работают на этой платформе (иногда даже лучше, чем на Windows), целый ряд соревновательных игр отказывается запускаться на ней именно по этой причине.
Сравнение подходов к безопасности
Те же принципы применимы к вредоносному ПО, хотя ландшафт угроз в Linux выглядит иначе. Политика Microsoft по проверке цифровых подписей драйверов привлекательна для бизнеса. Блокируя ядро, Windows обеспечивает уровень контроля и безопасности для борьбы с читами и вирусами, который невозможно достичь в более открытых системах без подобных ограничений. Для многих геймеров и компаний такой компромисс оправдан, несмотря на раздражение части пользователей.
Пользователи Linux пользуются беспрецедентным уровнем контроля, но та же свобода делает большинство античит-механизмов на стороне клиента бесполезными. Чтобы получить на Linux тот же уровень безопасности, что и в Windows, пришлось бы воссоздать все те же жесткие ограничения, из-за которых пользователи изначально и стремятся сменить систему. Тем не менее, Linux остается безопасным по целому ряду других причин: продвинутая система разрешений, оперативное исправление уязвимостей сообществом (даже если крупные баги, вроде xz-utils, иногда проскальзывают), меньшая рыночная доля, делающая ОС менее привлекательной целью, и установка ПО преимущественно через проверенные репозитории.
Свобода против контроля
Политика Microsoft в отношении подписей драйверов является неоспоримо эффективным инструментом безопасности. Требуя подписи и проверки всех драйверов ядра, корпорация создала одну из самых надежных защит потребительской ОС от низкоуровневых вредоносных программ и инструментов для читерства. Windows уникальна как платформа, способная поддерживать доверенную среду. Это одна из лучших функций безопасности, так как она действительно работает и вносит огромный вклад в защиту систем.
Однако эта безопасность имеет цену для потребителя. Она лишает пользователя контроля, передавая его центральному органу. Отсутствие возможности полностью управлять работой своей ОС вызывает протест у сторонников открытого программного обеспечения. В каком-то смысле Windows 11 рассматривает пользователя как недоверенную сторону, работающую с кодом ядра, предполагая, что каждый — включая самого владельца — может совершить опасное действие, если его не ограничить. С точки зрения безопасности это отличный пример снижения рисков, закрывающий один из самых опасных векторов атак. Но с точки зрения потребительских прав это ощущается как «аренда» функциональности собственного оборудования, где всё зависит от того, что разрешает или запрещает Microsoft. Встает вопрос: что будет, если эту концепцию расширят для «защиты» системы целиком? Например, как Microsoft отнесется к инструментам и скриптам для удаления предустановленного ПО, которые модифицируют систему? Для рядового пользователя принудительная подпись драйверов — бесспорно, отличный шаг, но последствия такого подхода остаются предметом дискуссий.
Последствия ограничений платформы для независимых разработчиков и пользователей
Ситуация, при которой разработчики программного обеспечения с открытым исходным кодом оказываются вытеснены с платформы из-за высоких затрат, связанных с разработкой собственного софта и его распространением среди других пользователей, вызывает серьезные опасения. Не менее негативным аспектом является ощущение отсутствия полноценного контроля над собственным «железом» до тех пор, пока Windows остается основным инструментом взаимодействия с ним.
