Опубликован эксплойт для уязвимости DirtyDecrypt в ядре Linux: локальное повышение привилегий до root на Fedora, Arch и openSUSE

linux

Исследователи из команды Zellic и V12 обнародовали работающий код подтверждения концепции (PoC) для уязвимости DirtyDecrypt, которая до недавнего времени считалась лишь теоретической угрозой. Теперь любой атакующий с локальным доступом к уязвимой системе может скопировать готовую команду и получить полные права суперпользователя. Проблема затрагивает дистрибутивы, в которых включён модуль безопасности RxGK для протокола RxRPC, использующийся в файловой системе AFS (Andrew File System). Это прежде всего Fedora (включая экспериментальную ветку Rawhide), Arch Linux и его производные, а также openSUSE Tumbleweed. В то же время многие корпоративные дистрибутивы, такие как Red Hat Enterprise Linux или Debian, отключают этот модуль в своих стандартных сборках.

Детали уязвимости

Согласно данным из открытых источников, уязвимость зарегистрирована под номером CVE-2026-31635. Однако официальное описание NVD (National Vulnerability Database) несколько расходится с реальной картиной: там говорится об ошибке, приводящей к отказу в обслуживании из-за перевёрнутой проверки длины в функции rxgk_verify_response(). На деле же код подтверждения концепции показывает куда более серьёзную проблему - локальное повышение привилегий (LPE) через запись в кеш страниц ядра.

Техническая суть DirtyDecrypt кроется в функции rxgk_decrypt_skb(). Когда ядро обрабатывает входящие токены RESPONSE в рамках протокола RxGK, оно расшифровывает данные до того, как проверяет код аутентификации сообщения (MAC). При этом сами данные находятся в структуре sk_buff, которая может ссылаться на страницы кеша, принадлежащие другим процессам или даже критическим системным файлам - например, /etc/shadow или SUID-двоичным файлам (файлам с битом SUID, позволяющим выполнение с привилегиями владельца). Поскольку механизм копирования при записи (copy-on-write) в этом сценарии не срабатывает, результат расшифровки напрямую перезаписывает чужие страницы памяти. Атакующий, контролируя шифротекст, может заменить содержимое любого читаемого SUID-файла на свою полезную нагрузку и затем запустить его - так он получает root без необходимости подбирать ключи или участвовать в гонках за копированием.

Команда исследователей, возглавляемая Луной Тонг (известной как cts/gf_256), подготовила эксплойт, который использует именно эту последовательность: rxgk_verify_response() → rxgk_extract_token() → rxgk_decrypt_skb() → skb_to_sgvec() → crypto_krb5_decrypt(). Принудительное шифрование под управлением атакующего на стороне сервера позволяет построить выбранный шифротекст для алгоритма AES-CBC (симметричного шифрования с обратной связью по шифротексту). В результате эксплойту удаётся отравить кеш страницы SUID-двоичного файла, а затем выполнить его - и получить привилегии root без дополнительных шагов.

Важно подчеркнуть, что DirtyDecrypt - это средство второго этапа атаки. Оно не даёт удалённого выполнения кода, а лишь превращает уже имеющийся доступ в полный контроль. Типичными начальными векторами проникновения становятся скомпрометированные учётные данные SSH, уязвимые веб-приложения или контейнеры с вредоносными образами. В контексте Kubernetes ситуация особенно опасна: если на воркер-узле кластера работает ядро с включённым RxGK, атакующий, получивший доступ к поду как непривилегированный пользователь, может через DirtyDecrypt сбежать из контейнера и захватить весь хост. После этого он получает доступ ко всем подам на узле, к сокетам среды выполнения контейнеров и к любым секретам Kubernetes, смонтированным на этом воркере.

На рабочих станциях разработчиков или инженеров эксплуатации, работающих под Fedora или Arch, локальное повышение до root означает прямой захват ключей доступа к облаку, конфигурационных файлов kubectl и закрытых ключей SSH. Часто именно эти креденшелы представляют большую ценность, чем сам взлом хоста.

Стабильные ядра начали получать исправления ещё в апреле 2026 года. Изначально разработчики устраняли только условие отказа в обслуживании, связанное с раздутыми аутентификаторами в rxgk_verify_response(). Соответствующие коммиты - a2567217..., beee051f..., e2f1a80d... - вошли в линейку стабильных обновлений. Однако, как отмечает эксперт под псевдонимом Moselwal, настоящая защита от локального повышения привилегий появилась позже - 10 мая 2026 года в коммите aa54b1d27fe0. Это изменение заставляет ядро копировать пакеты RXRPC DATA и RESPONSE, когда они содержат разделяемые фрагменты, чтобы расшифровка никогда не затронула страницы кеша, принадлежащие другим объектам. Данный патч возник в рамках работ по устранению смежных уязвимостей Copy Fail (CVE-2026-43284) и Dirty Frag (CVE-2026-43500), и теперь он автоматически защищает и путь DirtyDecrypt, хотя в записи NVD это не отражено.

Команды безопасности должны в первую очередь установить обновления ядра, включающие как апрельские исправления проверки длины, так и майский коммит aa54b1d27fe0. Если патч невозможно применить немедленно, рекомендуется временно отключить модули esp4, esp6 и rxrpc (с помощью выгрузки и внесения в черный список). Однако такая мера нарушит работу IPsec-VPN, использующих ESP, и монтирование разделов AFS. Поэтому её следует рассматривать только как краткосрочное решение до развёртывания исправленного ядра.

Обнаружить эксплуатацию DirtyDecrypt сложно: атакующий использует штатные пути ядра, и в традиционных системных журналах остаётся мало следов. Специалистам по мониторингу стоит организовать поиск по парку машин уязвимых версий ядер с проверкой настройки CONFIG_RXGK. Полезно также отслеживать вызов modprobe rxrpc (загрузку модуля) и вести наблюдение за процессами, меняющими свой идентификатор пользователя на root, если они не относятся к стандартным службам. Инструменты на базе eBPF (технологии выполнения кода в ядре без его модификации) - например, Falco - помогут выявить аномальную активность вокруг модуля RxGK.

В целом DirtyDecrypt продолжил семейство "грязных" уязвимостей ядра, в которое уже входят Copy Fail, Dirty Frag и Fragnesia. Все они основаны на субтильных ошибках при работе с кешем страниц и шифрованием на месте, что даёт атакующему примитив привилегированной записи. После публикации готового эксплойта каждый администратор, использующий дистрибутивы с RxGK, обязан оценить риски и как можно скорее применить патчи.

Ссылки

Комментарии: 0