Dirty Frag (CVE-2026-43284 и CVE-2026-43500)

Лабораторная работа по воспроизведению и обнаружению эксплойта для локального повышения привилегий в ядре Linux.

Статус: ПОДТВЕРЖДЕНО. Я выполнил воспроизведение, проверку без изменений на диске и обнаружение на уровне системных вызовов в лабораторной среде (ядро 6.18.9+kali-amd64). Этот документ — журнал лабораторной работы. Каждое утверждение ниже было зафиксировано в ходе воспроизведения. Скриншоты и артефакты — реальные снимки из виртуальной машины.

Содержание

• Обзор
• Почему это важно
• Технические детали
• Лабораторная среда
• Структура репозитория
• Контрольный список выполнения
• Процедура воспроизведения
• Инженерия обнаружения
• Реагирование на инциденты
• Смягчение
• Устранение неполадок
• Ссылки и благодарности
• Правовые и этические аспекты

Обзор

Dirty Frag объединяет две детерминированные логические ошибки в ядре Linux. Эти ошибки позволяют непривилегированному локальному пользователю перезаписать страничный кэш файлов, доступных только для чтения (например, /usr/bin/su), и получить root-оболочку:

Оба варианта используют тот же базовый шаблон, что и Dirty Pipe и Copy Fail. Системный вызов splice(2) помещает ссылку на страницу страничного кэша файла в слот frag в sk_buff на стороне отправителя. Атакующий может только читать этот файл. Затем код на принимающей стороне выполняет криптографическую операцию STORE на месте поверх этого frag. Это изменяет страничный кэш в оперативной памяти. Записи на диск не происходит, поэтому системы мониторинга целостности файлов (AIDE, Tripwire) не могут это обнаружить. Атака детерминирована. В ней нет гонки и нет паники ядра при сбое.

• Затронутый диапазон (согласно рекомендациям вышестоящего проекта):
  • Вариант ESP: с cac2661c53f3 (01.2017) до f4c50a4034e6 (исправлено 05.05.2026)
  • Вариант RxRPC: с 2dc334f1a63a (06.2023) до aa54b1d27fe0 (исправлено 10.05.2026)
• Публичный PoC: V4bel/dirtyfrag (раскрыт 07.05.2026)
• Рекомендации: CERT VU#980487, Red Hat Bugzilla 2467771
• Серьёзность (CVSS 3.1, по данным Canonical): CVE-2026-43284 = 8.8 (высокая), CVE-2026-43500 = 7.8 (высокая)

Почему это важно

Dirty Frag — это LPE без изменений на диске. Он повреждает страничный кэш в памяти, а не файл на диске. Традиционный мониторинг целостности файлов не может этого увидеть. Обнаружение должно происходить на уровне системных вызовов. Цепочка использует следующие примитивы системных вызовов: socket(AF_ALG)/socket(AF_RXRPC), splice и unshare(CLONE_NEWUSER|CLONE_NEWNET). Путь ESP также создаёт UDP-сокеты AF_INET и netlink-сокеты. Этот уровень является основным фокусом инженерии обнаружения в данном репозитории.

Технические детали

Оба варианта используют одно и то же слабое место: криптографию на месте, которая выполняет STORE байтов на страницу страничного кэша, которую атакующий размещает с помощью splice(2).

Вариант ESP (CVE-2026-43284)

1. Атакующий открывает пару UDP-сокетов на loopback и настраивает принимающую сторону с помощью UDP_ENCAP_ESPINUDP.
2. Он регистрирует поддельный ESP-заголовок (SPI, seq_no_lo и IV) в канале (pipe) с помощью vmsplice, затем 16 байт из /usr/bin/su по целевому смещению файла с помощью splice.
3. Один вызов splice перемещает данные из канала в отправляющий сокет. splice_to_socket() устанавливает MSG_SPLICE_PAGES. Это помещает страницу страничного кэша /usr/bin/su непосредственно в skb->frags[0].
4. При приёме выполняется следующая последовательность: xfrm4_udp_encap_rcv, затем xfrm_input, затем esp_input(). Уязвимая ветвь skip_cow () обходит . Она выполняет , используя страницу страничного кэша и как источник, и как назначение.

Атакующий контролирует и местоположение (смещение splice), и значение (4 байта). Проверка подлинности выполняется после операции записи, поэтому криптографический уровень никогда не помечает эту запись. Этот вариант требует CAP_NET_ADMIN и использует unshare(CLONE_NEWUSER|CLONE_NEWNET).

Вариант RxRPC (CVE-2026-43500)

rxkad_verify_packet_1() выполняет расшифровку одного блока pcbc(fcrypt) непосредственно на frag, закреплённом через splice в skb. Он не копирует данные предварительно. Атакующий выбирает сеансовый ключ (add_key("rxrpc", …)) так, чтобы decrypt(ciphertext) равнялся desired_plaintext. Это создаёт STORE размером 8 байт. Этот вариант нацелен на /etc/passwd. Ему не требуется пользовательское пространство имён. Он требует модуль rxrpc.ko (загружается по умолчанию в Ubuntu).

Результат эксплойта

Публичный PoC нацелен на /usr/bin/su. Он записывает 48 ESP-операций STORE по 4 байта каждая (192 байта по смещению файла 0). Он заменяет первые байты страничного кэша статическим ELF-файлом root-оболочки. Точка входа ELF выполняет setgid(0); setuid(0); setgroups(0,NULL); execve("/bin/sh", …). Один вызов execve("/usr/bin/su") затем даёт root-оболочку.

Исправление в вышестоящем проекте

Патч ESP (mainline f4c50a4034e6) помечает страничные frag, поступающие через splice(), флагом SKBFL_SHARED_FRAG. Ветвь skip_cow в esp_input() теперь также проверяет этот флаг. Skb с общими frag проходят через skb_cow_data() перед расшифровкой AEAD на месте.

Патч RxRPC (mainline aa54b1d27fe0) добавляет проверку skb->data_len рядом с существующей проверкой skb_cloned(). Ядро копирует нелинейный skb с разбитыми на страницы данными перед расшифровкой pcbc(fcrypt) на месте.

Лабораторная среда

Скриншот лабораторной настройки VirtualBox:

Структура репозитория

.
├── README.md                        # этот журнал лабораторной работы
├── detection/
│   ├── dirtyfrag.rules              # правила обнаружения auditd на уровне системных вызовов
│   ├── ausearch_dirtyfrag_observed.txt  # реальный вывод обнаружения эксплойта
│   ├── sigma/
│   │   └── dirty_frag_exploit.yml   # правило Sigma для обнаружения в SIEM
│   └── yara/
│       └── dirty_frag_exploit.yar   # правило YARA для кода PoC на диске/в памяти
├── mitigation/
│   └── dirtyfrag_mitigation.sh      # блокировка модулей + очистка страничного кэша
├── poc/
│   └── check_vulnerable.py          # неразрушающая предварительная проверка
├── reports/
│   └── incident-dirtyfrag.md        # сценарий реагирования на инциденты
└── screenshots/                     # реальные снимки из лабораторной ВМ

Контрольный список выполнения

• Предварительная проверка: запустить poc/check_vulnerable.py и подтвердить ядро/модули/userns
• Создать снимок VirtualBox (точка восстановления перед эксплуатацией)
• Создать непривилегированного testuser
• Клонировать и скомпилировать PoC от V4bel
• Запустить эксплойт и проверить root-оболочку
• Проверить отсутствие изменений на диске: зафиксировать хэши повреждённого и восстановленного /usr/bin/su
• Очистить заражённый страничный кэш (drop_caches или перезагрузка)
• Развернуть detection/dirtyfrag.rules и проверить оповещения auditd
• Создать правила Sigma и YARA на основе реального вывода auditd

Процедура воспроизведения

1. Проверка ОС и ядра (предварительная)

cat /etc/os-release | head -3
uname -r

Скриншот проверки версии ядра:

Ядро должно быть старше исправлений мая 2026 года (f4c50a4034e6 / aa54b1d27fe0). Если вы запускали apt upgrade после этой даты, эксплойт не сработает. См. Устранение неполадок.

2. Неразрушающая проверка уязвимости

Безопасный проверщик сообщает, является ли ВМ вероятной целью. Он проверяет работающее ядро, наличие модулей esp4/esp6/rxrpc и доступность непривилегированных пользовательских пространств имён. Вариант ESP требует этих пространств имён.

python3 poc/check_vulnerable.py

Ожидаемый вердикт: [*] potentially vulnerable -- proceed in a disposable VM only.

3. Создание непривилегированного тестового пользователя

Непривилегированный testuser имитирует атакующего без особых прав.

sudo useradd -m testuser
sudo passwd testuser
su - testuser
id

Скриншот: id показывает UID 1001. Это подтверждает доступ без root.

4. Клонирование и компиляция эксплойта

Из непривилегированной учётной записи:

git clone https://github.com/V4bel/dirtyfrag.git
cd dirtyfrag
gcc -O0 -Wall -o exp exp.c -lutil
./exp

При успехе эксплойт модифицирует страничный кэш /usr/bin/su. Он записывает 48 ESP-операций STORE по 4 байта каждая (ELF-файл root-оболочки размером 192 байта по смещению файла 0). Затем он запускает интерактивную root-оболочку с помощью forkpty.

Скриншот доступности модулей, проверки исходного кода и чистой компиляции:

5. Проверка повышения привилегий

id
whoami

Скриншот: id показывает uid=0(root) после ./exp.

6. Проверка отсутствия изменений на диске (повреждение только страничного кэша)

sha256sum читает через страничный кэш. Пока запись эксплойта активна, хэш отличается от исходного. После очистки хэш возвращается к исходному. Эта пара «до/после» доказывает, что двоичный файл на диске никогда не изменялся.

sha256sum /usr/bin/su     # 1) пока страничный кэш заражён -> ДРУГОЙ хэш

Скриншот: хэш отличается от хэша пакета (ОЗУ отравлено, диск нетронут).

Наблюдаемый повреждённый (страничный кэш) хэш: 3fc29078bd77150b5d6fbb368f632bf02c1a3704816f03fb694ec2e81e77bde4

7. Очистка после эксплойта и проверка восстановления (критически важно)

После эксплуатации страничный кэш содержит повреждённые данные. Всегда очищайте его:

echo 3 | sudo tee /proc/sys/vm/drop_caches
# или перезагрузите ВМ

Затем проверьте восстановление (как testuser):

sha256sum /usr/bin/su     # теперь совпадает с ИСХОДНЫМ хэшем пакета
su -                      # снова запрашивает пароль — автоматического root нет

Скриншот: восстановленный (исходный на диске) хэш.

Наблюдаемый исходный (на диске) хэш: 2b4f8770bd35bba5cdc5cfe292bc1d988e92ec1786bf91cf83e0e86fac056eb6

После перезагрузки dpkg -V util-linux не вернул никакого вывода. Файл /usr/bin/su на диске точно соответствует пакету, поэтому повреждённый хэш 3fc29078… существовал только в страничном кэше.

drop_caches может не удалить отравленную страницу. Это происходит, если работающий процесс всё ещё удерживает страницу. В этом случае sha256sum и dpkg -V продолжают показывать повреждённое содержимое. Надёжное решение — перезагрузка. Обратите внимание, что dpkg -V также читает через страничный кэш. Пока страница отравлена, он сообщает ??5?????? (MD5 отличается; размер, режим, владелец и mtime совпадают). После перезагрузки вывод снова становится пустым. Это доказывает, что файл на диске никогда не изменялся.

Очистка не отключает эксплойт. Она только удаляет отравленный страничный кэш. Модули необходимо отключить отдельно (см. Смягчение). Удаление уже загруженных модулей на скомпрометированном хосте требует перезагрузки.

Инженерия обнаружения

Dirty Frag невидим для мониторинга целостности файлов. Обнаружение сосредоточено на примитивах системных вызовов, которые цепочка обязана использовать.

Правила auditd (detection/dirtyfrag.rules)

# /etc/audit/rules.d/dirtyfrag.rules
-a always,exit -F arch=b64 -S socket -F a0=38 -F uid!=0 -k dirtyfrag_af_alg
-a always,exit -F arch=b64 -S socket -F a0=33 -F uid!=0 -k dirtyfrag_rxrpc
-a always,exit -F arch=b64 -S splice -F uid!=0 -k dirtyfrag_splice
-a always,exit -F arch=b64 -S unshare -F uid!=0 -k dirtyfrag_namespace
-w /usr/bin/su -p r -k dirtyfrag_suid_read

Примечание: AF_ALG = 38 и AF_RXRPC = 33 в Linux (см. /usr/include/bits/socket.h). В ранних черновиках использовалось a0=21. Это значение неверно. AF_RXRPC — это 33, а не 21.

Развёртывание и проверка:

sudo cp detection/dirtyfrag.rules /etc/audit/rules.d/
sudo systemctl restart auditd   # или: sudo auditctl -D && sudo auditctl -R /etc/audit/rules.d/dirtyfrag.rules
sudo auditctl -l

Ожидаемые оповещения после повторного запуска эксплойта (сопоставьте по PID):

ausearch -k dirtyfrag_af_alg
ausearch -k dirtyfrag_rxrpc
ausearch -k dirtyfrag_splice
ausearch -k dirtyfrag_namespace

Проверенный вывод обнаружения

Все пять правил загружены (auditctl -R, res=1 для каждого CONFIG_CHANGE). Правила зафиксировали настройку пространств имён эксплойтом:

time->Wed Aug  5 08:26:37 2026
type=PROCTITLE msg=audit(1785932797.328:592): proctitle="./exp"
type=SYSCALL msg=audit(1785932797.328:592): arch=c000003e syscall=272 success=yes exit=0 a0=50000000 a1=0 a2=0 a3=0 items=0 ppid=5198 pid=5199 auid=1000 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=pts2 ses=2 comm="exp" exe="/home/testuser/dirtyfrag/exp" subj=unconfined key="dirtyfrag_namespace"

Расшифровка: syscall=272 (unshare), a0=50000000 равно CLONE_NEWUSER | CLONE_NEWNET, uid=1001 (непривилегированный testuser), comm="exp". Полный журнал находится в detection/ausearch_dirtyfrag_observed.txt.

Скриншот: вывод ausearch показывает загрузку правил и событие эксплойта.

Покрытие обнаружения

Реагирование на инциденты

Полный сценарий находится в reports/incident-dirtyfrag.md: резюме для руководства, хронология, индикаторы компрометации, сопоставление с MITRE ATT&CK, сдерживание, устранение, восстановление и извлечённые уроки.

Смягчение

Немедленное смягчение во время выполнения. Оно не переживает перезагрузку для уже загруженных модулей (см. примечание ниже):

sudo mitigation/dirtyfrag_mitigation.sh

Что он делает:

1. Записывает /etc/modprobe.d/dirtyfrag.conf для блокировки esp4, esp6 и rxrpc. Он включает строки blacklist и alias … off. Простой однострочник пропускает эти строки (автозагрузка по алиасу в противном случае продолжала работать).
2. Удаляет модули, если они в данный момент загружены.
3. Очищает страничный кэш, чтобы удалить уже отравленные страницы.

Влияние: отключение этих модулей приводит к прекращению работы IPsec VPN (ESP) и файловой системы AFS (RxRPC).

Постоянное исправление: обновите ядро, содержащее патчи вышестоящего проекта. Или заблокируйте модули при загрузке (initcall_blacklist=esp4,esp6,rxrpc).

Устранение неполадок

Ссылки и благодарности

• Исследование, обнаружение и публичный PoC: Hyunwoo Kim (@v4bel), V4bel/dirtyfrag
• Техническое описание: assets/write-up.md
• Рекомендация CERT/CC: VU#980487
• Трекер CVE Red Hat: CVE-2026-43284 / bug 2467771

Правовые и этические аспекты

Этот репозиторий предназначен только для авторизованных оборонительных исследований в области безопасности и обучения.

• Все воспроизведения выполнялись в изолированной ВМ VirtualBox. После этого мы восстановили снимок.
• Не запускайте PoC на системах, которые вам не разрешено тестировать. Несанкционированная эксплуатация может быть уголовным преступлением.
• PoC и контент для обнаружения опубликованы в образовательных целях. Понимание атаки — основа её обнаружения. Полное заявление см. в DISCLAIMER.md.

Лицензия

См. LICENSE. Эта лабораторная работа предназначена для образовательного использования только в вашей собственной изолированной среде. Не запускайте PoC на системах, которые вам не разрешено тестировать.