cfDr — Доктор ошибок копирования

Copy Fail Detection and Remediation

Набор ролей и плейбуков Ansible для обнаружения и устранения CVE-2026-31431 (Copy Fail) — критической уязвимости локального повышения привилегий в модуле algif_aead ядра Linux.

Репозиторий

🔗 GitHub: https://github.com/parmstro/cfDr

Название cfDr — игра слов от «Copy Fail Doctor» — ваше надёжное средство от CVE-2026-31431.

---

Содержание

1. Понимание CVE-2026-31431
2. Доступные меры устранения
3. Методология обнаружения
4. Как работает cfDr
5. Влияние на системную криптографию
6. Рекомендуемый порядок действий
7. Дополнительные ресурсы
8. Мониторинг обновлений
9. Быстрый старт
10. Расширенная настройка

---

Понимание CVE-2026-31431

Что такое Copy Fail?

CVE-2026-31431 (CVSS 7.8) — логическая ошибка в интерфейсе сокетов AEAD ядра Linux (AF_ALG), обнаруженная в 2026 году. Уязвимость позволяет любому непривилегированному локальному пользователю повысить привилегии до root за считанные секунды.

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

• Затронутый компонент: модуль ядра algif_aead (криптоинтерфейс AF_ALG)
• Тип уязвимости: логическая ошибка в обработке операций копирования
• Вектор атаки: локальный
• Требуемые привилегии: отсутствуют (непривилегированный пользователь)
• Взаимодействие с пользователем: отсутствует
• Воздействие: полный компрометация системы (доступ root)

Затронутые системы

Версии ядра: Linux kernel >= 4.10 (выпущено в 2017)

Затронутые дистрибутивы:

• Red Hat Enterprise Linux 7, 8, 9
• CentOS 7, 8, 9 (и Stream)
• Fedora (все поддерживаемые версии)
• Ubuntu 17.04 и новее
• Debian 9 (Stretch) и новее
• SUSE Linux Enterprise 12, 15

Примечание: любой дистрибутив Linux с ядром 4.10 или новее потенциально уязвим.

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

Эта уязвимость особенно опасна, потому что:

1. Не требует привилегий — её может использовать любая учётная запись
2. Мгновенное повышение — доступ root за секунды
3. Широкое распространение — затрагивает более 7 лет выпусков ядра
4. Локальное выполнение — удалённый доступ не нужен, но атакующие, получившие начальную точку входа, могут немедленно повысить привилегии
5. Активная эксплуатация — доступны публичные эксплойты

Реальное влияние

Как только атакующий получает любую форму локального доступа (SSH, веб-шелл, побег из контейнера и т. д.), он может:

• Получить полный контроль над системой
• Установить постоянные бэкдоры
• Получить доступ к конфиденциальным данным
• Перемещаться по другим системам в сети
• Развернуть программы-вымогатели или криптомайнеры

---

Доступные меры устранения

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

Понимание уровней защиты

Не все меры устранения одинаковы. Вот что вам нужно знать:

Метод	Может ли root обойти?	Покрытие	Поддержка Enterprise Linux
Блокировка модуля	✅ Да (через insmod)	Предотвращает загрузку через modprobe	Все версии
Политика SELinux	❌ НЕТ (уровень LSM)	Только настроенные домены	Все версии (по умолчанию)
systemd seccomp	❌ НЕТ (фильтр системных вызовов)	Только настроенные службы	Все версии
eBPF LSM	❌ НЕТ (уровень LSM)	Системный уровень (если настроено)	RHEL 9+, Fedora 34+

Рекомендуемый подход: защита в глубину

Рекомендация cfDr по умолчанию: Флаг 3 (Блокировка модуля + SELinux)

Это обеспечивает два независимых уровня защиты:``` ┌─────────────────────────────────────────────────┐ │ Layer 1: Module Blacklist │ │ • Prevents modprobe algif_aead │ │ • Persists across reboots │ │ • CAN be bypassed by malicious root (insmod) │ ├─────────────────────────────────────────────────┤ │ Layer 2: SELinux Policy │ │ • Blocks AF_ALG socket() at syscall level │ │ • Works even if module is loaded │ │ • CANNOT be bypassed from userspace │ │ • Covers user_t, unconfined_t (majority cases) │ └─────────────────────────────────────────────────┘

Result: If either layer fails, the other still protects

### Почему одного чёрного списка модулей недостаточно

Решительный злоумышленник с root-доступом может обойти чёрный список модулей:```bash
# Module blacklist DOES NOT prevent:
insmod /lib/modules/$(uname -r)/kernel/crypto/algif_aead.ko.xz

Однако это допустимо, поскольку:

1. Уязвимость нацелена на повышение привилегий (непривилегированный → root)
2. Если злоумышленник уже имеет root, он может эксплуатировать напрямую без загрузки модуля
3. Чёрный список модулей защищает от основного вектора атаки

Полная стратегия защиты

Для полной, необходной защиты вам необходимо:

Чёрный список модулей + как минимум одно из:

• Политика SELinux (рекомендуется для Enterprise Linux)
• Фильтры systemd seccomp (защита на уровне служб)
• Программа eBPF LSM (только RHEL 9+, системная защита)

Справочник флагов смягчения

cfDr использует побитовые флаги для включения нескольких мер смягчения:

Значение флага	Включённые меры смягчения	Сценарий использования
1	Только чёрный список модулей	Минимальная защита, системы без SELinux
2	Только SELinux	Среды только с SELinux
3	Чёрный список модулей + SELinux	РЕКОМЕНДУЕМЫЙ вариант по умолчанию
5	Чёрный список модулей + seccomp	Без SELinux с усилением служб
7	Чёрный список модулей + SELinux + seccomp	Расширенная защита
15	Все меры смягчения	Максимальная защита (только RHEL 9+)

Расчёт флагов: 1 (чёрный список) + 2 (SELinux) + 4 (seccomp) + 8 (eBPF) = сумма

Пробелы в покрытии, о которых следует знать

Защита SELinux:

• Покрывает только домены, указанные в политике: user_t, unconfined_t, httpd_t, postgresql_t, mysqld_t
• Процессы, работающие в других доменах SELinux, могут быть не защищены
• На практике user_t и unconfined_t покрывают подавляющее большинство сценариев атак

Защита systemd seccomp:

• Защищает только явно настроенные службы
• Конфигурация по умолчанию покрывает: httpd, nginx, postgresql, mariadb, redis, memcached
• Процессы вне этих служб не защищены

Защита eBPF LSM:

• Требуется ядро 5.7+ (RHEL 9, Fedora 34+)
• Сложность требует экспертных знаний для корректной реализации
• Может обеспечить комплексную системную защиту при правильной настройке

---

Методология обнаружения

Как cfDr обнаруживает уязвимость

cfDr выполняет комплексную оценку по нескольким измерениям:

1. Проверка версии ядра```bash

uname -r

- Определяет, если версия ядра >= 4.10 (уязвимый диапазон)
- Идентифицирует выпуск ядра и дистрибутив

#### 2. Проверка доступности модуля```bash
modinfo algif_aead

• Проверяет наличие модуля algif_aead в ядре
• Проверяет расположение модуля и его метаданные

3. Статус загрузки модуля```bash

lsmod | grep algif_aead

- Определяет, загружен ли модуль в данный момент
- **Критически важно**: Загруженный модуль = активно эксплуатируемый

#### 4. Активное обнаружение сокетов```bash
lsof -U | grep AF_ALG

• Определяет активные сокеты AF_ALG
• Указывает на потенциальную активную эксплуатацию

5. Обнаружение существующих мер защиты