Защита процессоров Intel, которая должна мешать ядру Windows обращаться к памяти обычных программ, в некоторых системных вызовах оказывается заранее отключенной. Специалист по безопасности обнаружил такое поведение, когда разрабатывал демонстрационный эксплойт для уязвимого драйвера HackSys Extreme Vulnerable Driver.
Специалист использовал ошибку произвольной записи, чтобы перенаправить выполнение кода ядра и перенести стек в память пользовательского процесса. Подобная схема, казалось бы, должна была сразу завершиться сбоем из-за механизма Supervisor Mode Access Prevention (SMAP). Intel разработала SMAP именно для того, чтобы ограничить доступ к пользовательским страницам памяти из режима ядра.
Однако на виртуальной машине с Windows 11 сборки 26200.8328 цепочка успешно отработала и позволила получить права SYSTEM. Проверка показала, что SMAP был включен через бит 21 регистра CR4, но одновременно в регистре флагов процессора оказался установлен бит AC (Alignment Check, бит проверки выравнивания). Согласно документации Intel, установленный бит AC разрешает ядру обращаться к пользовательской памяти даже при активном SMAP.
Серия тестов показала, что состояние AC не зависело от пользовательской программы. Даже когда программа явно сбрасывала бит перед системным вызовом, драйвер все равно получал управление с AC=1. После того как AC принудительно сбрасывали уже внутри драйвера, попытка прочитать пользовательскую память немедленно приводила к сбою системы. Значит, сам механизм SMAP работал корректно, но Windows заранее разрешала доступ к такой памяти на исследованном пути обработки запроса.
Причина связана с архитектурой Windows. Еще в 2020 году специалисты Центра реагирования на угрозы безопасности Microsoft изучали, можно ли полноценно включить SMAP для обычного ядра. В опубликованной работе Microsoft пришла к выводу, что существующий код Windows слишком часто напрямую обращается к пользовательской памяти.
Когда специалисты Microsoft проверяли обычную загрузку системы, они насчитали около 2900 таких обращений в 994 функциях. Если инструкции, которые включают и отключают доступ к пользовательской памяти, добавлять автоматически, это замедляло системные вызовы примерно на 23%, а некоторые операции файловой системы – на 20–40%. Для защищенного ядра Windows такой подход оказался приемлемым, поскольку Microsoft полностью контролирует работающий там код.
Позднее в Windows появились специальные функции, которые позволяют безопасно обмениваться данными между ядром и пользовательской памятью. В актуальной документации Microsoft перечислены, в частности, RtlCopyFromUser и RtlCopyToUser. Однако модель, при которой весь код ядра обязан пользоваться только такими функциями, до сих пор не охватывает Windows целиком.
Результаты не означают, что SMAP полностью бесполезен в Windows. Проверку проводили на конкретной сборке Windows 11 и через путь обработки запросов драйвера. Но эксперимент показывает, что при эксплуатации некоторых уязвимых драйверов атакующий может получить управление в контексте, где доступ ядра к пользовательской памяти уже разрешен. Поэтому SMAP нельзя считать самостоятельной преградой для атак после выполнения кода в ядре.