DirtyFrag в Linux: CVE-2026-43284 и CVE-2026-43500, риск root-доступа и меры защиты

Уязвимость dirtyfrag linux связана с ESP и RxRPC: локальный пользователь может использовать ошибки ядра для повышения привилегий. Разбираем механику CVE-2026-43284 и CVE-2026-43500, команды проверки и временные меры до установки исправленного ядра.

DirtyFrag в Linux создает практический риск локального повышения привилегий на системах, где уязвимые подсистемы ядра доступны локальным пользователям. Термин «DirtyFrag» объединяет класс уязвимостей, связанных с некорректной обработкой фрагментированных пакетов и механизмами копирования данных в буферах сокета (skb). CVE-2026-43284 (NVD) показывает, как оптимизация производительности в сетевом стеке может превратиться в уязвимость повышения привилегий. Эта уязвимость затрагивает подсистему xfrm ESP (Encapsulating Security Payload), которая используется в IPsec-туннелях и защищенных соединениях.

Вторая уязвимость класса DirtyFrag, CVE-2026-43500, связана с модулем RxRPC, который используется файловой системой AFS. На момент подготовки материала запись CVE может отсутствовать в NVD, поэтому статус нужно сверять по трекерам дистрибутивов и первичным публикациям. В этом сценарии опасна проверка RxRPC-пакета в rxkad_verify_packet_1(): первые 8 байт полезной нагрузки расшифровываются на месте, и при подстановке страниц через splice() ядро может перезаписать фрагмент страничного кэша читаемого файла. В отличие от ESP-варианта, атакующий не получает прямую запись произвольных байт: он подбирает ключ и rxkad-токен так, чтобы результат расшифрования дал нужные байты. Практический риск — изменение содержимого вроде /etc/passwd в кэше, например попытка заменить root:x:0:0: на root::0:0:. Поэтому временные меры должны учитывать не только esp4 и esp6, но и rxrpc, если AFS/RxRPC не используется в инфраструктуре.

Механика CVE-2026-43284 заключается в ошибке обработки страниц, разделяемых между процессами (shared pipe pages). Когда данные передаются через UDP-сокеты с использованием флага MSG_SPLICE_PAGES, страницы из канала напрямую прикрепляются к структуре skb. В корректной реализации, например в TCP, такие skb помечаются флагом SKBFL_SHARED_FRAG после вызова skb_splice_from_iter(). Это сигнализирует последующим этапам обработки, что данные не принадлежат только этому сокету и требуют создания копии перед модификацией. Однако в путях добавления дейтаграмм IPv4/IPv6 этот флаг не устанавливался при сплайсинге страниц в UDP skb.

В результате пакет ESP-in-UDP, созданный из общих страниц канала, выглядел для ядра как обычный неклонируемый нелинейный skb. Подсистема ввода ESP, стремясь к производительности, выбирала быстрый путь без копирования (no-COW fast path) для неклонируемых skb без списка фрагментов. Это приводило к расшифровке данных «на месте» (in-place) поверх областей памяти, которые не принадлежали исключительно этому skb. Поскольку данные были общими, злоумышленник мог добиться повреждения page cache и подмены содержимого защищенных файлов в кэше; в опубликованной цепочке эксплуатации это используется для получения root.

Исправление, описанное в разборе oss-security и представленное в стабильных ветках ядра Linux, решает эту проблему двумя шагами. Во-первых, фрагменты splice для дейтаграмм IPv4/IPv6 теперь маркируются флагом SKBFL_SHARED_FRAG, что унифицирует поведение с TCP. Во-вторых, ввод ESP теперь проверяет наличие этого флага и переключается на функцию skb_cow_data() (copy-on-write), если флаг установлен. Это гарантирует, что ESP не будет расшифровывать внешние фрагменты на месте, предотвращая несанкционированный доступ к общим областям памяти.

Для администраторов это означает одно: сначала сверить наличие исправленного ядра у своего вендора, затем отдельно оценить, используются ли ESP и RxRPC в рабочей инфраструктуре. Временное отключение esp4, esp6 или rxrpc снижает поверхность атаки только там, где эти модули действительно не используются.

Оценка риска для корпоративной инфраструктуры требует понимания метрик CVSS. Агентство CISA-ADP присвоило CVE-2026-43284 базовый балл 7.8 (HIGH) по шкале CVSS v3.1. Вектор уязвимости определяется как CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H. Хотя вектор указывает на локальный вектор атаки (AV:L) и высокую сложность (AC:H), последствия компрометации максимальны: полный доступ к конфиденциальности, целостности и доступности (C:H/I:H/A:H) с изменением области действия (S:C). Это означает, что успешная эксплуатация позволяет выйти за пределы изоляции процесса.

Для корпоративных серверов, особенно тех, которые выполняют функции шлюзов или обрабатывают зашифрованный трафик, наличие уязвимости в подсистеме xfrm ESP создает прямую угрозу повышения привилегий. Злоумышленник, имеющий локальный доступ с низкими привилегиями (PR:L), может подготовить специальные структуры данных в памяти, используя механизмы splice. Если локальный процесс доводит UDP-пакеты, инкапсулирующие ESP, до уязвимого пути ядра, обработка может затронуть общие страницы вместо частной копии. Это открывает путь к повреждению page cache и подмене данных в кэше, что в практических цепочках эксплуатации используется для повышения привилегий.

Практический риск локальных уязвимостей часто недооценивают, если защита сосредоточена только на периметре. Компрометация веб-приложения с правами непривилегированного пользователя может стать началом цепочки до root-доступа через уязвимость ядра. В случае с DirtyFrag, даже если внешний фаервол блокирует прямые атаки на порты IPsec, внутренние сервисы, использующие UDP-инкапсуляцию или взаимодействующие с подсистемой xfrm, остаются важной частью оценки риска. Локальный пользователь может инициировать создание сокетов и управление памятью, необходимое для триггера уязвимости.

Критичность также обусловлена распространенностью IPsec в корпоративных сетях VPN. Серверы, выступающие в роли endpoint’ов для site-to-site туннелей или удаленного доступа, постоянно обрабатывают ESP-пакеты. Если ядро уязвимо, локальный процесс с доступом к нужным сетевым и memory-management примитивам может потенциально участвовать в цепочке эксплуатации. Хотя сложность атаки высока, ключевой фактор — точное управление layout skb/page-cache и splice-backed страницами, а не классическое состояние гонки.

Кроме того, изменение области действия (Scope Changed) в векторе CVSS указывает на то, что уязвимость влияет на ресурсы за пределами компонента, в котором она возникла. Это означает, что атака на подсистему сети может привести к компрометации данных приложений, баз данных или конфигурационных файлов, находящихся под управлением других процессов. Для аудиторов безопасности это сигнал о необходимости немедленной проверки всех систем, где включена поддержка IPsec, RxRPC/AFS или используются специфические сетевые оптимизации, такие как zero-copy networking.

Первым шагом в оценке воздействия уязвимости DirtyFrag становится инвентаризация версий ядер на всех узлах инфраструктуры. Администраторы должны сравнить текущие версии с версиями, содержащими исправления, но делать это нужно по бюллетеням конкретного дистрибутива. Команда uname -r предоставляет базовую информацию, но для точного определения необходимо обращаться к таблицам безопасности вендора. Например, в RHEL, Ubuntu или Debian номера патчей могут отличаться от upstream-версии ядра из-за backport-исправлений.

Для российских дистрибутивов, таких как ALT Linux, Astra Linux, RED OS и ROSA, ситуация требует особого внимания. Администраторы не должны предполагать наличие патча только на основе версии ядра upstream. Необходимо мониторить официальные бюллетени безопасности вендоров. Если публичного подтверждения закрытия CVE в конкретном дистрибутиве нет, статус системы следует считать неподтвержденным и проверять его через поддержку или закрытые бюллетени поставщика.

Второй этап проверки — выявление активных сервисов, использующих подсистемы xfrm, ESP и RxRPC. Даже если ядро уязвимо, отсутствие активных IPsec-соединений и AFS/RxRPC снижает вероятность успешной атаки, хотя и не устраняет риск полностью. Используйте команду lsmod для проверки загрузки модулей esp4, esp6, xfrm_user и rxrpc. Наличие этих модулей в памяти повышает приоритет проверки.

Также важно проверить конфигурацию сетевых интерфейсов на предмет использования UDP-инкапсуляции IPsec (NAT-Traversal). Команда ip xfrm state покажет активные состояния безопасности (Security Associations), а ip xfrm policy show — политики XFRM. Если вывод пуст, риск снижается, но не исчезает, так как локальный пользователь может попытаться создать новые ассоциации, если это разрешено политиками и выданными capabilities.

Для комплексной оценки мы рекомендуем использовать инструменты сканирования уязвимостей, которые поддерживают проверку версий ядра против баз CVE. Однако автоматические сканеры могут пропустить логические уязвимости, такие как DirtyFrag, если они не обновлены до последних сигнатур. Поэтому ручная проверка конфигурации и версий остается обязательной. Особое внимание следует уделить серверам в DMZ, VPN-шлюзам, Kubernetes/Docker-хостам и системам, где используются IPsec или AFS/RxRPC.

Защита от уязвимости DirtyFrag строится из двух частей: краткосрочного снижения поверхности атаки и планового обновления ядра. Экстренные меры направлены на снижение поверхности атаки до применения патча. Если обновление ядра невозможно прямо сейчас, рассмотрите временное отключение модулей ESP и RxRPC только там, где они не нужны рабочим сервисам. Команды rmmod esp4, rmmod esp6 и rmmod rxrpc могут прервать IPsec VPN, strongSwan/Libreswan, AFS/RxRPC и зависимые сервисы, поэтому такой шаг нужно согласовать с владельцами процессов.

Более мягкая мера — ограничение прав на создание IPsec-ассоциаций. Убедитесь, что только привилегированные пользователи (root) могут управлять политиками xfrm. Проверьте настройки CAP_NET_ADMIN и другие capabilities Linux, которые могут быть делегированы непривилегированным процессам. Если приложение не требует прямого управления IPsec, эти права должны быть отозваны. Также можно использовать SELinux или AppArmor для ограничения доступа к AF_KEY, netlink-сообщениям xfrm и AFS/RxRPC там, где это поддерживается политиками безопасности.

Если модули точно не используются, их можно временно заблокировать до установки исправленного ядра через файл в /etc/modprobe.d/. Такая мера не заменяет патч и должна сопровождаться проверкой зависимых сервисов: IPsec VPN, site-to-site туннелей, AFS/RxRPC, резервного доступа и средств мониторинга.

Долгосрочный план должен включать регулярное обновление ядра Linux по каналу конкретного дистрибутива. Для производственных сред новые ядра нужно тестировать в изолированном контуре перед развертыванием. Обновление должно сопровождаться перезагрузкой сервера или подтвержденным live patch от вендора, так как изменения в ядре не вступают в силу для уже загруженного ядра без одного из этих механизмов.

Для виртуализированных сред убедитесь, что гипервизор также обновлен, если он использует общие компоненты ядра или модули безопасности. В контейнерных средах (Docker, Kubernetes) обновление ядра хоста обязательно, так как контейнеры используют ядро хост-системы. Изоляция namespaces не защищает от уязвимостей повышения привилегий в ядре. После обновления повторно проверьте версию ядра, загруженные модули и активные XFRM/RxRPC-состояния.

Не забывайте про мониторинг. Настройте алерты на попытки загрузки модулей ядра и необычную активность в подсистемах XFRM, ESP и RxRPC. Долгосрочная стратегия должна включать автоматизацию проверки наличия патчей для всех новых CVE, связанных с ядром, чтобы сократить время реакции в будущем.

Даже при наличии патчей, риск компрометации сохраняется из-за задержек в обновлении или наличия неизвестных уязвимостей. Здесь роль профессионального IT-аутсорсинга становится критической. Команда сопровождения обновляет серверы, контролирует состояние систем и реагирует на инциденты. В случае подозрения на эксплуатацию уязвимости DirtyFrag, наши инженеры проводят форензику системы: анализ дампов памяти, журналов ядра и сетевой активности. Это позволяет определить, была ли попытка атаки успешной, и какие данные могли быть затронуты.

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

Также проводится аудит правил iptables/nftables и конфигураций IPsec на предмет несанкционированных изменений. Злоумышленник, получивший root-права, часто оставляет бэкдоры, которые трудно обнаружить без специализированного опыта.

Отдельный важный аспект — восстановление доверия к инфраструктуре. Специалисты помогают пересмотреть архитектуру безопасности, внедряя принципы наименьших привилегий и сегментации сети. Если уязвимость была использована для lateral movement (перемещения внутри сети), проводится полная проверка всех связанных систем. На практике быстрое реагирование и прозрачная коммуникация с клиентом минимизируют бизнес-потери и репутационные риски.

Кроме того, IT-аутсорсинг обеспечивает доступ к экспертизе, которая может отсутствовать в штате компании. Специалисты сопровождения отслеживают глобальные угрозы, такие как DirtyFrag, и заранее предлагают меры защиты до того, как атака станет массовой. В зону ответственности сопровождения входит тестирование патчей в staging-среде, что исключает риск простоя production-серверов из-за несовместимости обновлений. Это особенно важно для компаний с высокой нагрузкой на серверы, где каждая минута простоя приводит к потерям.

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

Для российских Linux-дистрибутивов проверка DirtyFrag должна идти через официальные каналы конкретного поставщика. Astra Linux, ALT Linux, RED OS и ROSA могут поставлять исправления с backport-патчами, поэтому номер ядра не всегда совпадает с upstream-версией Linux. Администратору нужно сверять не только uname -r, но и пакет ядра в репозитории, дату последнего обновления, бюллетень безопасности и статус конкретной CVE у вендора.

В инфраструктуре с сертифицированными контурами обновление ядра нельзя проводить как обычную пакетную операцию. Сначала фиксируют список узлов, где загружены esp4, esp6, xfrm_user, ipcomp4, ipcomp6 или rxrpc, затем проверяют зависимые сервисы: IPsec VPN, site-to-site туннели, AFS/RxRPC и средства резервного доступа. Если модуль не используется, его временное отключение снижает поверхность атаки до установки исправления, но такой шаг нужно согласовать с владельцами сетевых сервисов.

Практичный порядок работ: получить бюллетень вендора, проверить тестовый сервер, подтвердить загрузку нового ядра после перезагрузки, затем обновлять production-узлы партиями. После каждого окна обслуживания полезно сохранить вывод uname -r, lsmod | grep -E "esp4|esp6|rxrpc|xfrm|ipcomp", ip xfrm state и ip xfrm policy show. Эти артефакты показывают аудиторам, что уязвимость DirtyFrag проверена не формально, а по реальному состоянию хоста.

Ответы на часто задаваемые вопросы по теме статьи.

Константин Тютюнник — основатель IT For Prof, 15 лет практики в IT-аутсорсинге для B2B. Специализация: Linux-инфраструктура, DevOps, импортозамещение и информационная безопасность для малого и среднего бизнеса.

GitHub  ·  Habr  ·  ТенЧат  ·  ВКонтакте