CVE-2026-31431: Обнаружение и защита от обхода существующих систем детектирования через io_uring

Авторы: fz0x00, qiwuSEC

Исследование

Для CVE-2026-31431 («Copy Fail») мы продемонстрировали системные слабости в массовых продуктах безопасности, объединив три стратегии обхода: асинхронный путь ввода-вывода io_uring, разделение процессов (fork + SCM_RIGHTS) и повторное использование сокетов. В ходе эмпирического тестирования мы доказали, что эти техники позволяют обойти практически все инструменты детектирования, основанные на системных вызовах.

Ключевые выводы

1. io_uring обходит практически все системы детектирования на основе системных вызовов

io_uring отправляет запросы через разделяемые кольцевые буферы памяти, минуя традиционные точки входа системных вызовов. Это означает:

auditd / Wazuh / Elastic Security Agent и другие продукты, зависящие от аудита системных вызовов, полностью слепы, когда атакующие используют путь io_uring — ноль событий, ноль оповещений
Рабочие потоки io_uring (iou-wrk-XXXXX) выполняют операции внутри ядра, не запуская audit_syscall_entry()
Политики Seccomp, блокирующие только socket(AF_ALG), можно обойти через IORING_OP_SOCKET — seccomp проверяет только на входе системного вызова, а операции io_uring не проходят через эту точку входа

2. Разделение процессов нарушает корреляцию на уровне PID

Используя fork + SCM_RIGHTS (передача fd через Unix domain socket), создание сокета и операции splice можно разместить в разных процессах:

Корреляция Wazuh same_field(audit.pid) ломается — PID сокета ≠ PID splice, правило CRITICAL не срабатывает
Отслеживание fd на уровне процессов в Falco libsinsp полностью нарушается в сценариях SCM_RIGHTS

3. Повторное использование сокетов обходит правила порогового подсчёта

Оригинальный PoC создаёт новый сокет на каждой итерации (что даёт 40+ вызовов socket(AF_ALG)). Повторное использование сокета создаёт только один слушающий сокет; цикл вызывает accept(), который не порождает новых событий сокета. Правила, основанные на count >= N, полностью обходятся.

4. Самая сложная для обнаружения комбинация вариантов

путь io_uring + splice + /etc/passwd + алгоритм authenc + разделение SCM_RIGHTS + повторное использование сокета

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

5. Мониторинг на уровне LSM может идеально обнаруживать эксплуатацию

__sock_create(family=38) — это необходимая точка схождения для всех путей (системные вызовы и io_uring) — AF_ALG — единственный пользовательский крипто-API в ядре Linux. Как бы атакующие ни варьировали подход, они обязаны создать сокет AF_ALG. Мониторинг этой функции на уровне LSM обеспечивает 100% полноту обнаружения и не зависит от вариантов атаки.

Результаты тестирования по продуктам

Продукт	Уровень детектирования	Традиционный системный вызов	Путь io_uring	Разделение процессов	Повторное использование сокета	Оценка
Tetragon (kprobe)	Функция ядра	✅	✅	✅	✅	Единственное полное покрытие цепочки
Falco + плагин krsi	fexit/fentry	✅	✅	✅	✅	Требуется krsi для io_uring; только на входе
Falco (modern_ebpf)	tracepoint системных вызовов	✅	❌	✅	✅	io_uring полностью невидим
auditd / Wazuh	аудит системных вызовов	✅	❌	❌ PID сломан	⚠️	Слеп к io_uring + нарушена корреляция PID
Elastic Security Agent	системные вызовы	✅	❌	⚠️	⚠️	Аналогично Wazuh; зависимость от системных вызовов = слепота

Falco требует плагин krsi

Собственный драйвер Falco modern_ebpf захватывает только путь системных вызовов. Плагин krsi обязателен — он использует трассировку fexit на выходах функций ядра io_socket() и __sys_socket(), чтобы покрыть путь io_uring для создания сокетов AF_ALG. Рекомендуемое запасное правило:

- rule: AF_ALG Socket Created
  condition: >
    (evt.type = socket and evt.args contains AF_ALG) or
    (evt.type = krsi_socket and krsi.domain = 38)
  output: >
    AF_ALG socket created (source=%evt.type domain=%evt.arg.domain
    krsi_domain=%krsi.domain proc=%proc.name pid=%proc.pid)
  priority: WARNING
  tags: [cve-2026-31431, crypto, container_escape]

Подход к обнаружению в рекомендуемом правиле: одновременно покрываются события socket (путь системных вызовов, с использованием строкового сопоставления evt.args contains AF_ALG для обхода ограничения типа ENUMFLAGS32) и события krsi_socket (путь io_uring, с целочисленным сравнением krsi.domain = 38). Без пороговых счётчиков (обходятся повторным использованием сокета), без зависимости от корреляции PID (обходится разделением процессов).

Примечание: Все три уровня защиты в правиле сообщества ThreatBear обходимы — несоответствие типа ENUMFLAGS32 (evt.arg[0]=38 всегда ложно), повторное использование сокета обходит пороговый счётчик (count=1 < 40), разделение процессов нарушает корреляцию PID. См. Анализ обхода правила.

Wazuh / Elastic Security Agent не могут обнаружить эксплуатацию через io_uring

Wazuh полностью полагается на события аудита системных вызовов auditd. Операции io_uring не проходят через вход системных вызовов, поэтому auditd выдаёт ноль событий, и все 7 правил Wazuh не срабатывают. То же самое относится к Elastic Security Agent — продукты, зависящие от входа системных вызовов, структурно слепы к пути io_uring. См. Анализ ограничений Wazuh.

Демонстрация обхода

Каталог bypass_demo/ содержит концептуальные описания подходов к обходу детектирования. Фактический код PoC предназначен только для внутреннего использования и не распространяется публично.

Индекс документации

Теория

Документ	Содержание
VULNERABILITY.md	Корневая причина — наложение трёх изменений ядра, цепочка атаки из 9 шагов, характеристики записи в page cache
EXPLOIT_VARIANTS.md	6 измерений вариантов эксплуатации — путь ввода-вывода × отправка данных × целевой файл × алгоритм AEAD × разделение процессов × повторное использование сокета
DETECTION_THEORY.md	Теория детектирования — точки схождения и расхождения, 4-уровневая архитектура детектирования, многосигнальная временная корреляция

CVE-2026-31431-detection-defense

Популярное