Драйвер компьютерной игры Street Fighter V отключает встроенный механизм защиты Windows25.09.2016 15:18

Драйверы компьютерных игр, которые используются для защиты целостности файлов игры, а также легитимности данных игроков не являются редкостью. Ранее публиковалось несколько обзоров наиболее известных подобных драйверов, например, nProtect GameGuard и Blizzard Lockdown. Такие драйверы могут использовать в своих целях перехваты API-вызовов на уровне ядра Windows, постоянное сканирование виртуального адресного пространства процессов, отслеживание доступа операций к системному реестру и др.

8b2f99a684ed4acf978e200ac3f67144.jpeg

Несколько дней назад компания Capcom уведомила своих пользователей об обновлении anti-hack драйвера (Capcom.sys), который используется для контроля за целостностью файлов игры и предотвращает возможную компрометацию содержимого памяти процесса игры с целью предотвращения читерства. Однако, пользователей в этом обновлении ждал неприятный сюрприз в одной из функций драйвера. Она позволяет отключать защитную меру ядра SMEP и исполнять код по указателю, полученному из пользовательского режима.

SMEP (Supervisor Mode Execution Prevention) уже является довольно известной мерой, о которой было написано несколько обзоров. Она требует поддержки как со стороны микропроцессора, так и со стороны ОС (Windows 8+). SMEP используется для блокирования операции исполнения кода пользовательского режима (Ring 3) в режиме ядра (RIng 0). Как бы это не выглядело странно (код режима ядра является самым привилегированным и имеет возможность доступа ко всей памяти в системе), SMEP является хорошей мерой для блокирования активности LPE-эксплойтов, которые часто передают управление на блок кода, расположенный в пользовательской части виртуального адресного пространства.

Драйверы Windows организованы таким образом, что для взаимодействия с клиентом из Ring 3, используется специальный интерфейс под названием IOCTL. Драйвер регистрирует специальный обработчик в ядре Windows, который может быть использован из пользовательского режима известной API-функцией DeviceIoControl. Приложение при использовании этого API передает драйверу код требуемой функции, набор аргументов и указывает входной, а также выходной буферы памяти для передачи аргументов и получения результата.

Новое обновление Capcom.sys использует интерфейс IOCTL и две функции с кодами 0xAA012044, 0xAA013044. Особенность этих функций заключается в том, что они позволяют клиенту пользовательского режима исполнить код в режиме ядра по указателю, полученному оттуда, причем перед этим отключает SMEP. После исполнения функции SMEP включается обратно установкой соответствующего бита регистра CR4. Очевидно, что отключение используется для исполнения кода в режиме ядра из пользовательского режима.

04bef557a01c4078b86f70718338c9ae.jpg
Рис. Функция Capcom.sys, которая исполняет указанную в IOCTL-запросе функцию с отключенным SMEP.

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

Компания Capcom уже выпустила обновление игры, закрывающее данную уязвимость.

We are in the process of rolling back the security measures added to the PC version of Street Fighter V. After the rollback process to the PC version, all new content from the September update will still be available to players. We apologize for the inconvenience and will have an update on the time-frame for the PC rollback solution soon.

Комментарии (3)

  • 25 сентября 2016 в 12:41 (комментарий был изменён)

    +5

    ↑

    ↓

    Компания Capcom уже выпустила обновление игры, закрывающее данную уязвимость.

    Я так понимаю, этого мало. Нужно отозвать цифровую подпись драйвера, чтобы никто не мог воспользоваться старой, дырявой версией, включив её в свой exploit pack

  • 25 сентября 2016 в 13:06 (комментарий был изменён)

    +3

    ↑

    ↓

    Вот так примерно и выглядит добрая половина драйверов режима ядра от сторонних производителей. Людям нужно было решить проблему, и они ее решили, а как это выглядит с точки зрения безопасности — всем наплевать. Вот еще один пример похожего поведения.
    The ASUS «Generic Function Service» includes a couple of drivers, ASMMAP.sys / ASMMAP64.sys,
    the version resources describe them as «Memory mapping Driver».

    This description is very accurate, it has a pair of ioctls, 0×9C402580 and 0×9C402584, that map or
    unmap to the calling process' address space ANY PART OF PHYSICAL MEMORY, with READ/WRITE permissions.
    Using code that has been copypasta’d a bunch of times, but seems to originate from a sample driver for NT 3.1.
    1993 vintage code, everybody.

    It also has a couple of other ioctls that allocate or free some RAM and gives the physical and virtual pointers
    to it, and another one that can make any I/O request (does in/out byte/word/dword with parameters given in the ioctl buffer, and returns the result for the case of in).

  • 25 сентября 2016 в 14:28 (комментарий был изменён)

    0

    ↑

    ↓

    Сразу вспомнился драйвер защиты Frost от Innova Systems, печально известный тем, что одна из его версий без возражений принимала управляющие команды от любого приложения. Сам драйвер умел, например, скрывать указанные процессы и был подписан валидной цифровой подписью. Эдакий «официальный» руткит.

© Habrahabr.ru