Уязвимость в Trend Micro Deep Security Agent для Linux позволяет локально вызывать временную брешь в защите

Trend Micro Deep Security

Исследователь безопасности обнаружил в Trend Micro Deep Security Agent (агент глубокой защиты) для Linux критическую особенность, которая превращает механизм восстановления работы продукта в оружие для атакующего. Оказалось, что локальный непривилегированный пользователь может спровоцировать агента на выгрузку собственных модулей ядра, отвечающих за мониторинг поведения. В результате на короткое, но повторяемое время защита конечной точки полностью отключается.

Детали уязвимости

Проблема заключается в том, как агент обрабатывает высокую локальную нагрузку. Если на защищённом узле запустить "шторм событий" - серию обычных операций с файлами и процессами в большом объёме, - компонент ds_am.init, входящий в состав агента, принимает решение выгрузить модули ядра bmhook и tmhook. Первый из них, bmhook, реализует собственно мониторинг поведения (поведенческий анализ). Второй, tmhook, представляет собой слой перехвата системных вызовов на основе механизма livepatch (способ динамического обновления ядра Linux без перезагрузки). Выгрузка происходит посредством команды rmmod. После этого модули загружаются заново, но в течение примерно одной-двух секунд ядро остаётся без поведенческого анализатора.

Исследователь использовал инструмент bpftrace для трассировки, чтобы доказать, что именно процесс агента, а не какая-то внешняя причина, инициирует удаление модулей. Логи ядра (dmesg) чётко фиксируют циклы выгрузки и повторной загрузки tmhook: сначала начинается переход livepatch в обратную сторону, затем модуль удаляется, создаётся так называемый "хлебный крошка" (breadcrumb file), после чего модуль загружается снова и livepatch завершает включение. Полный цикл занимает около 20 секунд, причём сам модуль отсутствует чуть более секунды. Однако bmhook исчезает ещё раньше, а значит, поведенческий мониторинг прекращается до того, как будет выгружен tmhook.

Для демонстрации практического влияния исследователь сравнил поведение защиты в обычном режиме и во время окна перезагрузки. В штатном состоянии агент блокировал скачивание тестового вредоносного образца и удалял его с диска. Когда же та же операция выполнялась в момент, когда bmhook и tmhook были выгружены, файл успешно записывался и оставался на диске. Это доказывает, что решение о блокировке меняется из-за отсутствия мониторинга.

Почему такой временный сбой важен? На первый взгляд, модули возвращаются, и защита восстанавливается. Но атакующий, уже имеющий непривилегированный доступ к системе (например, через скомпрометированную учётную запись разработчика или начальный вредонос), может синхронизировать свои действия с окнами уязвимости. За одну-две секунды можно записать вредоносный файл, переименовать его, изменить права доступа, запустить краткосрочный процесс или распаковать вторую стадию атаки. Поскольку триггер - это обычный шторм событий, который может генерировать любой локальный процесс, злоумышленник способен вызывать такие окна многократно, выполняя по одному опасному действию за раз.

Исследователь классифицирует проблему как ошибку защиты механизма (CWE-693 - отказ защитного механизма) и неконтролируемое потребление ресурсов (CWE-400). Серьёзность оценена как высокая, поскольку обход защиты воспроизводится в лабораторных условиях и может быть использован для доставки вредоносного кода. При этом уязвимость не является удалённой, не повышает привилегии и не приводит к постоянному отключению агента. Речь идёт именно о временной, но контрируемой бреши.

Важно подчеркнуть, что проблема не связана с какими-то экзотическими системными вызовами. Шторм событий состоит из обычных операций: создание, запись, усечение, переименование файлов, работа с символьными ссылками и порождение короткоживущих процессов. Именно такая нагрузка заставляет внутренний механизм предотвращения зацикливания (loop prevention) запустить процедуру восстановления, которая радикально снимает все хуки.

Пока уязвимости не присвоен номер CVE (реестр общеизвестных уязвимостей), и исследователь сообщает, что отправлял отчёт в Trend Micro ещё в феврале 2026 года, но не получил окончательного вердикта или сроков исправления. После нескольких месяцев ожидания он принял решение опубликовать результаты.

Администраторам систем, использующих Trend Micro Deep Security Agent на Linux, стоит обратить внимание на этот вектор. Полностью исключить риск локального шторма событий сложно, поскольку он имитирует нормальную активность. Возможно, временной мерой может стать усиление контроля за процессами, способными генерировать высокую нагрузку, а также настройка порогов срабатывания механизма loop prevention, если такая возможность предусмотрена вендором. Однако главный вывод исследования - даже надёжная защита конечных точек может иметь слепые зоны, которые создаёт она сама.

Ссылки

Комментарии: 0