Что такое DirtyFrag (краткая версия)

DirtyFrag — это цепочка локального повышения привилегий, построенная на двух независимых примитивах записи в page-cache ядра Linux: один в пути расшифровки на месте xfrm/ESP (IPsec) (CVE-2026-43284), а другой — в пути RxRPC (CVE-2026-43500). Каждый из них позволяет непривилегированному локальному пользователю записывать контролируемые атакующим байты в страницы page-cache, доступные только для чтения, например, в кэшированный образ setuid-root-бинария, такого как /bin/su, и оттуда получить root. Запись происходит только в памяти; файл на диске никогда не изменяется, поэтому мониторинг целостности файлов ничего не видит. Это тот же класс ошибок, что и Dirty Pipe и Copy Fail. Два CVE намеренно объединены в цепочку: если один путь недоступен в данной среде, работает другой.

На этом хосте непривилегированные пользовательские пространства имён ограничены AppArmor (kernel.apparmor_restrict_unprivileged_userns = 1), что блокирует половину цепочки, связанную с ESP. Остаётся путь RxRPC, который открывает сокет AF_RXRPC (семейство адресов 33) — и именно этот шаг убивает данная политика.

Настоящее решение — исправленное ядро. Всё здесь — временная мера для хоста, который вы пока не можете пропатчить. Ubuntu выпустила исправления DirtyFrag некоторое время до этого теста, так что это известная N-day, а не живой 0-day — суть в том, чтобы показать, что может сделать контроль времени выполнения на хосте, который по какой-то причине всё ещё работает на уязвимом ядре.

Политика: две точки удушения

Полная политика: block-dirtyfrag.yaml. Она устанавливает два kprobe.

Хук 1 — сокеты для подготовки (sys_socket). Основной контроль. Путь RxRPC эксплойта должен вызывать socket(AF_RXRPC, …) при каждом запуске, независимо от того, загружен ли уже какой-либо модуль ядра. Политика срабатывает по семейству адресов:

• Семейство 33 (AF_RXRPC) → Sigkill. На любом хосте, который не является клиентом AFS, практически ничто легитимное не открывает сокет AF_RXRPC, поэтому тотальное убийство здесь безопасно и с высокой степенью уверенности.
• Семейство 38 (AF_ALG) → Post (только аудит, без убийства). AF_ALG — это пользовательский API криптографии ядра, и у него есть легитимные пользователи (cryptsetup, инструментарий libkcapi, некоторые FIPS-процессы). Убийство только по семейству вызвало бы ложные срабатывания, поэтому здесь происходит только логирование. Путь к принуждению: аудит в течение некоторого времени, создание белого списка NotIn из наблюдаемых бинарников, затем рассмотрение возможности повышения до Sigkill.

Хук 2 — автозагрузка уязвимого модуля (security_kernel_module_request). Защита в глубину. Срабатывает, когда ядро запрашивает автоматическую загрузку семейства уязвимых модулей (esp4, esp6, rxrpc, псевдонимы сокетов net-pf-33/net-pf-38, криптошаблоны pcbc/fcrypt). Ограничение: он срабатывает, только если модуль еще не загружен — после первого запуска эксплойта в рамках загрузки эти модули загружаются, и хук замолкает. Это уровень холодной загрузки, а не основной контроль.

Вместе: Хук 1 ловит эксплойт независимо от того, прогреты модули или нет; Хук 2 добавляет более раннее, более специфическое срабатывание на холодном хосте.

Тестовая среда и воспроизводимость (прочитайте, прежде чем доверять результату)

• Результат смягчения получен на ядре 6.8.0-88-generic, которое уязвимо (базовый уровень достигает root). На машине также установлено 6.8.0-134-generic — исправленное ядро, и это было подтверждено напрямую: перезагрузка в -134 заставляет PoC самостоятельно терпеть неудачу (rc=4, без root), с политикой или без неё (см. примечание ниже). Чтобы воспроизвести демонстрацию смягчения, загрузите 6.8.0-88 через GRUB (он всё ещё установлен) — на любом исправленном ядре нечего смягчать.
• Это один хост, одна загрузка. Он демонстрирует механизм; это не исследование ложных срабатываний. Прежде чем вводить что-то подобное в эксплуатацию, сначала запустите его в режиме аудита на репрезентативных рабочих нагрузках, особенно для части AF_ALG.
• BPF LSM не включён (активные LSM: lockdown,capability,landlock,yama,apparmor — нет bpf). Поэтому принуждение использует Sigkill от kprobe, а не внутриядерный запрет LSM. Убийство происходит на системном вызове socket() — до примитива записи — так что процесс завершается на обязательном раннем этапе, а не «блокирует саму уязвимость».

Пошаговое выполнение

Шаги 1–5 выполняются на одной и той же загрузке 6.8.0-88 (уязвимое ядро).

1. Окружение — Ubuntu 24.04.4, ядро 6.8.0-88-generic, Tetragon v1.7.0 активен под systemd, непривилегированные пользовательские пространства имён ограничены.

2. Предусловия (политика ВЫКЛ) — чистая отправная точка: уязвимые модули не загружены, состояние xfrm отсутствует, политика не загружена.

3. Базовый уровень (политика ВЫКЛ) — эксплойт работает. Это доказывает, что ядро действительно уязвимо; вся заметка на этом держится.

4. Загрузка политики.

5. Принуждение (политика ВКЛ) — убийство. Эксплойт завершается сигналом при вызове socket() и никогда не достигает su:

Структурированное событие подтверждает и совпадение, и убийство — process_kprobe на системном вызове сокета, затем process_exit по сигналу для того же PID:

action kprobe читается как KPROBE_ACTION_POST, потому что действие Post — это то, что генерирует видимое событие; действие Sigkill — это то, что приводит к отдельному выходу SIGKILL. Два события вместе являются доказательством: совпадение и убийство.

Примечание: в сыром захвате 07 также содержится строка message из более ранней версии политики (до того, как часть AF_ALG была выделена в режим только аудита). Совпадение по family: 33 и последующий SIGKILL идентичны во всех версиях; отличается только этот текст.

Примечание об исправленном ядре (6.8.0-134)

После выполнения на уязвимом ядре хост был перезагружен в 6.8.0-134-generic (исправленное ядро Ubuntu) и PoC был запущен снова:

Будем точны в том, что это показывает:

• Это не результат смягчения. При выключенной политике эксплойт уже терпит неудачу (rc=4, без root), потому что ядро исправлено. Политике нечего предотвращать. Сравнение «до/после», несущее утверждение о смягчении, существует только на уязвимом ядре -88.
• Что это действительно показывает — что хук сокета не зависит от версии ядра: PoC по-прежнему вызывает socket(AF_RXRPC), поэтому Tetragon по-прежнему отправляет ему SIGKILL и регистрирует попытку в журнале, как на исправленном ядре, так и на неисправленном. Это имеет ценность как обнаружение попытки и как защита в глубину, но это не то же самое, что остановка работающего эксплойта.

Ограничения и честные оговорки

• Хук 1 (семейство 33) предполагает, что хост не является клиентом AFS. На клиенте AFS AF_RXRPC легитимен, и тотальное убийство сломает его. Проверьте на каждом узле.
• Часть AF_ALG по замыслу работает только в режиме аудита. Вариант, использующий только путь AF_ALG с уже загруженными модулями, будет залогирован, но не убит, пока вы не переведёте эту часть в режим принуждения (после создания белого списка).
• Хук 2 бездействует, когда модули уже загружены — он срабатывает только на холодном хосте.
• Убийство происходит на системном вызове сокета. Это работает, потому что в данном PoC сокет AF_RXRPC открывается до примитива записи. Такой порядок делает раннее убийство эффективным; это не гарантия для любого возможного эксплойта.

Ссылки

• PoC и заметка автора — https://github.com/V4bel/dirtyfrag
• Трекер CVE Ubuntu — https://ubuntu.com/security/CVE-2026-43284 · https://ubuntu.com/security/CVE-2026-43500
• Бюллетень Red Hat RHSB-2026-003 (охватывает оба CVE)
• Документация Tetragon — https://tetragon.io/docs/

Настройка: Tetragon v1.7.0 автономный, запущен через systemctl; политики загружены с помощью tetra tracingpolicy add.