Dirty Frag: семь лет без патча и никакого предупреждения

Уязвимость, которая даёт root на большинстве Linux-машин с 2017 года, — это не просто очередной CVE с высоким баллом. Это симптом того, как работает модель ответственного раскрытия, когда одна из сторон нарушает эмбарго. Называется Dirty Frag, напоминает Dirty Pipe, но последствия шире: патча нет, а предупреждения от разработчиков ядра не было — всё потому, что исследователь опубликовал эксплойт до того, как его успели закрыть.

Если коротко: баг в обработке IP-фрагментов в сетевом стеке Linux позволяет локальному пользователю с минимальными правами повысить привилегии до root. Для эксплуатации нужен доступ к машине, но в контейнерных средах и мультитенантных архитектурах это может означать полную компрометацию хоста. Подробности в оригинале.

Что показывает этот случай

Во-первых, время жизни уязвимости — с 2017 года. Это не ошибка новичка, а логическая дыра, которая не ловилась статическими анализаторами и не проявлялась в тестах. Такие баги — норма для сложного кода, но их поиск и закрытие требуют координации, которая в случае Dirty Frag дала сбой.

Во-вторых, нарушение эмбарго — не редкость. Когда исследователь видит, что патч не готов, а сроки тикают, он может принять решение публиковать. Это не всегда злой умысел: иногда давление сообщества или заказчика толкает на такой шаг. Но результат один — администраторы узнают об угрозе из новостей, а не из уведомления от вендора.

Что делать, пока нет патча

Патча нет, но есть обходные пути. Первое — ограничить приём IP-фрагментов там, где это возможно. В современных сетях фрагментация почти не используется: большинство интерфейсов имеют MTU 1500 и выше, а IPv6 её вообще избегает. Если вы не работаете с VPN-туннелями или специфическими протоколами вроде NFS поверх UDP, можно смело дропать фрагментированные пакеты на уровне iptables/nftables.

Второе — ужесточить контроль за локальными пользователями и контейнерами. Dirty Frag требует локального доступа, поэтому минимизация поверхности: read-only rootfs, seccomp, AppArmor, отказ от привилегированных контейнеров — всё это снижает риск.

Третье — мониторинг. Если у вас есть SIEM или система обнаружения аномалий, добавьте сигнатуры на попытки эксплуатации: нестандартные комбинации флагов IP-фрагментов, превышение количества фрагментов на сессию. Это не даст 100% гарантии, но повысит шанс заметить атаку до того, как она завершится.

Почему это не про панику, а про дисциплину

На нашем опыте, критическая уязвимость без патча — не повод сворачивать инфраструктуру, а повод пересмотреть процессы реагирования. Мы обычно рекомендуем клиентам иметь playbook для таких сценариев: кто принимает решение о временных мерах, как быстро можно применить iptables-правила на всех хостах, есть ли возможность изолировать подозрительные поды. Если playbook есть — Dirty Frag становится неприятной, но управляемой ситуацией. Если нет — начинается хаос.

И ещё один вывод: не все CVE одинаково опасны в вашей конкретной среде. Dirty Frag — локальный эксплойт. Если ваши серверы не принимают код от непроверенных пользователей, а контейнеры работают с минимальными правами — реальный риск может быть ниже, чем кажется из заголовка. Но проверять это нужно до инцидента, а не после.