В предыдущих постах нашего корпоративного блога мы несколько раз касались темы поддержки подсистемы Linux на Windows 10 (WSL), а также описывали особенности ее технической реализации. Бета-версия этой подсистемы была доставлена пользователям в выключенном виде в рамках обновления Windows 10 Redstone 1 (Anniversary Update) в августе этого года.
Недавно Microsoft начала анонсировать изменения в ядре Windows, которые помогут AV-драйверам правильным образом работать с процессами подсистемы Linux, в контексте которых запускаются исполняемые ELF-файлы.
Известно, что до появления механизмов функций обратного вызова для контроля за различными операциями в режиме ядра, авторы драйверов брандмауэров и антивирусов использовали перехваты API-вызовов в системной таблице вызовов KiServiceTable, которую можно было обнаружить с использованием экспортируемой ядром переменной KeServiceDescriptorTable. С появлением новых уже документированных API-вызовов для регистрации callback-функций, разработчики перешли на их использование. К тому же 64-разрядные версии Windows не позволяли просто так перехватывать сервисы KiServiceTable изначально.
Рис. Архитектура файловой системы WSL. Видно, что LXCore.sys эмулирует различные объекты Linux с использованием функций ядра Windows.
Одной из основных операций, которая контролируется антивирусами или HIPS является создание процессов и потоков. Драйвер может зарегистрировать функцию обратного вызова с помощью PsSetCreateProcessNotifyRoutineEx, а также PsSetCreateThreadNotifyRoutine. После этого при создании процессов или потоков в процессе, драйвер будет получать уведомление об этой операции. Microsoft модернизировала эти функции, добавив API PsSetCreateProcessNotifyRoutineEx2 и PsSetCreateThreadNotifyRoutineEx. Эти API-функции ядра помогут драйверам отслеживать активность внутри процессов подсистемы Linux.
» Microsoft опубликовала информацию о реализации VFS в подсистеме Linux на Windows 10
» Microsoft раскрыла технические аспекты реализации подсистемы Linux в Windows 10
» Microsoft подтвердила слухи об интеграции подсистемы Linux в Windows 10
» Включение подсистемы Linux в Windows 10
Недавно Microsoft начала анонсировать изменения в ядре Windows, которые помогут AV-драйверам правильным образом работать с процессами подсистемы Linux, в контексте которых запускаются исполняемые ELF-файлы.
Известно, что до появления механизмов функций обратного вызова для контроля за различными операциями в режиме ядра, авторы драйверов брандмауэров и антивирусов использовали перехваты API-вызовов в системной таблице вызовов KiServiceTable, которую можно было обнаружить с использованием экспортируемой ядром переменной KeServiceDescriptorTable. С появлением новых уже документированных API-вызовов для регистрации callback-функций, разработчики перешли на их использование. К тому же 64-разрядные версии Windows не позволяли просто так перехватывать сервисы KiServiceTable изначально.
Рис. Архитектура файловой системы WSL. Видно, что LXCore.sys эмулирует различные объекты Linux с использованием функций ядра Windows.
Одной из основных операций, которая контролируется антивирусами или HIPS является создание процессов и потоков. Драйвер может зарегистрировать функцию обратного вызова с помощью PsSetCreateProcessNotifyRoutineEx, а также PsSetCreateThreadNotifyRoutine. После этого при создании процессов или потоков в процессе, драйвер будет получать уведомление об этой операции. Microsoft модернизировала эти функции, добавив API PsSetCreateProcessNotifyRoutineEx2 и PsSetCreateThreadNotifyRoutineEx. Эти API-функции ядра помогут драйверам отслеживать активность внутри процессов подсистемы Linux.
Type = PsCreateProcessNotifySubsystems; //новый тип уведомлений
Status = PsSetCreateProcessNotifyRoutineEx2(Type, Callback,TRUE); //новая API
void Callback (_In_ HANDLE ParentId, _In_ HANDLE ProcessId, _Inout_opt_ PPS_CREATE_NOTIFY_INFO CreateInfo) {
if (CreateInfo->Flags.IsSubsystemProcess == 0) {
/* Код оригинального обработчика callback */
} else {
Type = ProcessSubsystemInformation;
Status = NtQueryInformationProcess(ProcessHandle, Type, &Subsystem, sizeof(Subsystem), NULL);
if (Subsystem == SubsystemInformationTypeWSL) {
/* Новый код для обработки создания процессов WSL */
}
}
}
Type = PsCreateThreadNotifySubsystems; //новый тип уведомлений
Status = PsSetCreateThreadNotifyRoutineEx(Type, Callback); //новая API
void Callback (_In_ HANDLE ProcssId, _In_ HANDLE ThreadId, _In_ BOOLEAN Create) {
Type = ThreadSubsystemInformation;
Status = NtQueryInformationThread(ThreadHandle, Type, &Subsystem, sizeof(Subsystem), NULL);
if (Subsystem == SubsystemInformationTypeWin32) {
/* Код оригинального обработчика callback */
} else if (Subsystem == SubsystemInformationTypeWSL) {
/* Новый код для обработки создания процессов WSL */
}
}
» Microsoft опубликовала информацию о реализации VFS в подсистеме Linux на Windows 10
» Microsoft раскрыла технические аспекты реализации подсистемы Linux в Windows 10
» Microsoft подтвердила слухи об интеграции подсистемы Linux в Windows 10
» Включение подсистемы Linux в Windows 10
Поделиться с друзьями
Комментарии (5)
OldMaster
07.11.2016 19:56Перехваты API-вызовов в системной таблице вызовов KiServiceTable позволяли антивирусам блокировать создание процесса. А новый механизм callback-функций может уведомить только о уже свершившемся факте. Вирус уже запустился и вот хэндл его процесса.
Если антивирусные компании перешли на новый механизм, то очень зря.
third112
Существует мнение, что использование виртуальной машины может спасти от многих новых неизвестных антивирусам вирусов. А в статье (если правильно понял) противоположное решение. Почему? В Microsoft считают, что ВМ не спасает?
oYASo
Я не настоящий сварщик, но вроде бы уже давно все мало-мальски серьезные вирусы научились определять, что их запустили в виртуальной среде и ничего плохого при этом не делать.
third112
И отлично! Если они не будут пытаться делать и таких плохих вещей, как на хост пересесть (а это возможно?), то и пусть себе на ВМ (т.е. в гостевой ОС) ничего плохого не делают. А после перезагрузки эту ВМ с вирусами сотру и новую запущу: скопировать ВМ — мгновенное дело, каждый запуск можно свежую копию ставить.
ChALkeRx
Вы, наверное, хотите https://www.qubes-os.org/.
Но учитите, что в системах виртуализации тоже бывают дыры, из свежего: https://ruxcon.org.au/assets/2016/slides/Breaking%20out%20of%20QEMU_v3.pdf
Учитите, что самое ценное сейчас — данные пользователя, затем идут вычислительные или сетевые ресурсы (кто-то их переставит местами, впрочем). Хост может и не быть никому особо нужен.
Так что чтобы только виртуалка вас спасла, у вас в ней не должно быть ничего ценного (ни в какой момент времени) и она должна чистится (как вы и сказали).