Dirty Frag («грязный фрагмент») — новая цепочка уязвимостей в ядре Linux, через которую обычный локальный пользователь может получить root-доступ, то есть права администратора системы. Риск касается популярных дистрибутивов, включая Ubuntu, RHEL, Fedora, openSUSE, CentOS Stream и AlmaLinux.

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

Что нашли в ядре Linux

Dirty Frag относится к классу локального повышения привилегий — LPE (от англ. local privilege escalation — локальное повышение прав). Такой баг сам по себе не даёт злоумышленнику войти на сервер извне. Но если он уже получил доступ к учётной записи с низкими правами, уязвимость может поднять его до root.

Исследователь Hyunwoo Kim описал Dirty Frag как развитие идей Dirty Pipe и Copy Fail. В отличие от многих старых атак на ядро Linux, цепочка не зависит от узкого окна по времени и не требует «гонки процессов». Это делает эксплуатацию стабильнее: при неудачной попытке ядро, по словам исследователя, не падает, а шанс успеха остаётся высоким.

Цепочка собирает две проблемы с записью в page cache — кэш страниц, через который Linux работает с данными файлов и памяти. Первая находится в подсистеме xfrm-ESP, связанной с IPsec. Вторая — в RxRPC. По отдельности они зависят от конфигурации системы, но вместе закрывают слабые места друг друга.

Какие системы попали в зону риска

В описании исследователя среди уязвимых систем названы Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10 и Fedora 44. Это не значит, что все установки этих систем одинаково легко атаковать: многое решают настройки ядра, доступные модули и ограничения для пользователей.

На Ubuntu создание пользовательских namespace часто блокирует AppArmor, поэтому один путь атаки через xfrm-ESP может не сработать. Но там по умолчанию может быть загружен модуль rxrpc.ko, и тогда помогает вторая часть цепочки. В RHEL 10.1, по данным исследователя, rxrpc.ko в стандартной сборке не поставляют, зато могут остаться другие условия для атаки.

Одна из причин тревоги — возраст корней проблемы. Уязвимость xfrm-ESP связывают с изменением кода от января 2017 года. RxRPC-вариант появился позже, в июне 2023 года. Значит, под риском могут оказаться не только свежие тестовые установки, но и давно живущие серверы с обновлёнными дистрибутивами.

Что известно о CVE и патчах

Для xfrm-ESP Page-Cache Write уже указан идентификатор CVE-2026-43284. Этот дефект, по данным публикации, исправили в основной ветке ядра Linux. Для RxRPC Page-Cache Write указан CVE-2026-43500, но на момент описания источника готового патча для него ещё не было.

Отдельная сложность — у Dirty Frag есть пересечения с Copy Fail, но старые меры против Copy Fail не закрывают новый риск полностью. Например, блокировка модуля algif_aead не спасает от Dirty Frag, потому что новая цепочка может сработать без него.

Для компаний это типичная ситуация, когда список «мы уже закрыли прошлую дыру» быстро устаревает. Похожий урок дала и история с утечками в приложениях: важно проверять не только сам факт обновления, но и конкретный путь атаки. Мы разбирали такую логику на примере уязвимости Ollama с риском утечки ключей API и переписок.

Почему контейнеры не всегда спасают

Контейнеры снижают риск, но не превращают уязвимость ядра в безобидную ошибку. Если контейнер запускает произвольную стороннюю нагрузку, а профиль безопасности слишком мягкий, локальное повышение прав может помочь выйти за границы контейнера или атаковать хост.

Эксперты Wiz описали Dirty Frag как цепочку из двух примитивов записи в page cache. Для атаки нужны доступ к уязвимым интерфейсам ядра и возможность работать с буферами, связанными со страницами памяти, например через пути на базе splice. В более жёстких средах Kubernetes с типовыми seccomp-профилями эксплуатация сложнее, потому что часть опасных системных вызовов и привилегий закрыта.

Тем не менее полагаться только на контейнеризацию нельзя. Ядро у хоста общее, и ошибка в нём затрагивает все процессы. Если на сервере крутятся тестовые сборки, CI-задачи, плагины, пользовательские скрипты или песочницы для анализа файлов, риск растёт.

Следы атак уже ищут в журналах

Microsoft сообщила о «ограниченной активности» в реальных атаках, где злоумышленники пытались поднять привилегии через команду su. Компания не утверждает, что видит только Dirty Frag: такие следы могут совпадать и с Copy Fail. Но сценарий выглядит тревожно — сначала внешний доступ по SSH, затем интерактивная оболочка, запуск ELF-файла и попытка получить более высокие права.

После этого атакующие, по данным Microsoft, меняли файл LDAP-аутентификации GLPI, изучали каталог GLPI и конфигурацию системы, смотрели артефакты эксплойта и работали с PHP-сессиями. Часть файлов они удаляли или затирали, вероятно, чтобы нарушить активные сессии и скрыть следы.

Для обычных пользователей это не повод искать «волшебную кнопку» в настройках браузера или сети. Жалобы уровня «не работает мобильный интернет МТС» относятся к диагностике связи, а не к Dirty Frag. Если же сервер внезапно получил новые root-процессы, неизвестные ELF-файлы и странные изменения в веб-приложениях, это уже зона расследования.

Что сделать сейчас

  • Проверьте, какие серверы и рабочие станции используют Linux-дистрибутивы из зоны риска: Ubuntu 24.04.4, RHEL 10.1, Fedora 44, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10 и близкие сборки.
  • Установите доступные обновления ядра и следите за бюллетенями своего поставщика Linux. Для CVE-2026-43284 исправление уже попало в основную ветку ядра, для CVE-2026-43500 нужны новые уведомления.
  • До выхода всех патчей обсудите с администратором временную блокировку модулей esp4, esp6 и rxrpc, если они не нужны вашему серверу. Не отключайте сетевые компоненты наугад на продакшен-системах.
  • Проверьте журналы SSH, запуск неизвестных ELF-файлов, подозрительные обращения к su, изменения в GLPI, LDAP-настройках и PHP-сессиях.
  • Ограничьте запуск стороннего кода на Linux-хостах. Для контейнеров используйте строгие профили seccomp, минимальные привилегии и запрет лишних возможностей ядра.
  • Не администрируйте серверы из публичных сетей без защиты соединения. Для работы в кафе, аэропортах и коворкингах используйте сервис безопасного интернет-соединения, чтобы снизить риск перехвата данных.
  • Держите тестовые машины отдельно от рабочих данных. Такой подход полезен не только для Linux: обновления и бета-сборки тоже требуют осторожности, о чём мы писали в материале про новые сборки Windows 11 и безопасность.
Поделиться: