28.09.2020

Выпуск модуля LKRG 0.8 для защиты от эксплуатации уязвимостей в ядре Linux


Проект Openwall опубликовал выпуск модуля ядра LKRG 0.8 (Linux Kernel Runtime Guard), предназначенного для выявления и блокирования атак и нарушений целостности структур ядра. Например, модуль может защитить от несанкционированного внесения изменений в работающее ядро и попыток изменения полномочий пользовательских процессов (определение применения эксплоитов). Модуль подходит как для организации защиты от уже известных эксплоитов для ядра Linux (например, в ситуациях когда в системе проблематично обновить ядро), так и для противостояния эксплоитам для ещё неизвестных уязвимостей. Код проекта распространяется под лицензией GPLv2.

Среди изменений в новой версии:

  • Изменено позиционирование проекта LKRG, который теперь не разделяется на отдельные подсистемы для проверки целостности и определения применения эксплоитов, а преподносится как целостный продукт для выявления атак и различных нарушений целостности;
  • Обеспечена совместимость с ядрами Linux с 5.3 по 5.7, а также с ядрами, собранными с агрессивными оптимизациями GCC, без опций CONFIG_USB и CONFIG_STACKTRACE или с опцией CONFIG_UNWINDER_ORC, а также с ядрами, в которых отсутствуют перехватываемые LKRG функции, если без них можно обойтись;
  • При сборке обеспечена проверка некоторых обязательных настроек ядра CONFIG_* для формирования осмысленных сообщений об ошибках вместо неясных сбоев;
  • Добавлена поддержка ждущего (ACPI S3, suspend to RAM) и спящего (S4, suspend to disk) режимов;
  • В Makefile добавлена поддержка DKMS;
  • Реализована экспериментальная поддержка 32-разрядных платформ ARM (протестировано на Raspberry Pi 3 Model B). Ранее доступная поддержка AArch64 (ARM64) дополнена обеспечением совместимости с платой Raspberry Pi 4;
  • Добавлены новые обработчики (hook), в том числе обработчик вызова capable() для лучшего определения эксплоитов, манипулирующих «capabilities«, а не идентификаторами процессов (credentials);
  • Предложена новая логика определения попыток выхода из ограничений пространств имён (например, из контейнеров Docker);
  • На системах x86-64 обеспечена проверка и применение бита SMAP (Supervisor Mode Access Prevention), предназначенного для блокирования доступа к данным в пространстве пользователя из привилегированного кода, выполняемого на уровне ядра. Защита SMEP (Supervisor Mode Execution Prevention) была реализована ранее;
  • В процессе работы обеспечено размещение настроек LKRG в странице памяти, обычно доступной только для чтения;
  • Добавлены проверки, допускающие вывод важных сведений, таких как информация об адресах в ядре, только в логи с уровнем 4 и выше.
  • Повышена масштабируемость БД отслеживания процессов — вместо одного дерева RB, защищаемого одним spinlock, задействована хэш таблица из 512 деревьев RB, защищённая 512 блокировками чтения-записи;
  • Реализован и включён по умолчанию режим, при котором проверка целостности идентификаторов процесса часто выполняется только для текущей задачи, а также опционально для активируемых (waking up) задач. Для остальных задач, находящихся в состоянии сна или работающих без обращения контролируемому в LKRG API ядра, проверка выполняется реже.
  • Добавлены новые sysctl и параметры модуля для тонкой настройки LKRG;
  • Настройки по умолчанию изменены для достижения более взвешенного баланса между оперативностью выявления нарушений и эффективностью реакции с одной стороны, и влиянием на производительность и риском ложных срабатываний с другой;
  • Unit-файл systemd переработан для загрузки модуля LKRG на раннем этапе загрузки (для отключения модуля может использоваться параметр командной строки ядра);
  • Разработчик дистрибутива Whonix начал формирование готовых пакетов с DKMS для Debian, Whonix, Qubes и Kicksecure.

С учётом предложенных в новом выпуске оптимизаций снижение производительности при применении LKRG 0.8 оценивается на уровне 2.5% в режиме максимальной защиты и 2% при отключении некоторых проверок.

В недавно проведённом исследовании эффективности пакетов для выявления руткитов LKRG показал лучшие результаты, без ложных срабатываний определив 8 из 9 протестированных руткиков, работающих на уровне ядра (были выявлены руткиты Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit и Sutekh, но пропущен Keysniffer, который является модулем ядра с кейлоггером, а не руткитом в прямом смысле). Для сравнения пакеты AIDE, OSSEC и Rootkit Hunter выявили 2 руткита из 9, а Chkrootkit не выявили ни одного. При этом LKRG не поддерживает определение руткитов, размещаемых в пространстве пользователя, поэтому наибольшая эффективность достигается при использовании связки AIDE и LKRG, позволившей выявить 14 из 15 руткитов всех типов.

Проверка целостности в LKRG выполняется на основе сравнения хэшей, вычисляемых для наиболее важных областей памяти и структур данных ядра (IDT (Interrupt Descriptor Table), MSR, таблицы системных вызовов, все процедуры и функции, обработчики прерываний, списки загруженных модулей, содержимое секции .text модулей, атрибуты процессов и т.п.). Процедура проверки активируется как периодически по таймеру, так и при наступлении различных событий в ядре (например, при выполнении системных вызовов setuid, setreuid, fork, exit, execve, do_init_module и т.п.).

Определение возможного применения эксплоитов и блокирование атак производится на стадии до предоставления ядром доступа к ресурсам (например, до открытия файла), но после получения процессом несанкционированных полномочий (например, смена UID). При выявлении несанкционированного поведения процессов выполняется их принудительное завершение, чего достаточно для блокирования многих эксплоитов.

Источник: https://www.opennet.ru/opennews/art.shtml?num=53244

Добавить комментарий