Ни одна из ошибок по отдельности не является полностью надёжной — путь через ESP требует возможности создания пользовательского пространства имён (которое блокирует AppArmor в Ubuntu), а путь через RxRPC требует загрузки rxrpc.ko (чего большинство дистрибутивов по умолчанию не делают). Вместе они закрывают слепые зоны друг друга, делая цепочку работоспособной практически на всех крупных дистрибутивах.

Существует публичный proof-of-concept. Считайте, что он уже активно используется.

Что делает этот скрипт

Он проверяет вашу систему на условия, делающие эксплуатацию возможной, и сообщает конкретно, почему вы уязвимы — а не просто «да» или «нет».

Он ничего не исправляет. Он ничего не эксплуатирует. Он просто сообщает правду о вашей системе.

Требования

• Python 3.6+
• Без внешних зависимостей — только стандартная библиотека
• Root не требуется (намеренно — мы проверяем то, что может видеть непривилегированный атакующий)

Использование

Вот и всё. Цветной вывод, конкретные причины для каждого результата и сводка по устранению в конце.

Скриншот

[]

Как исправить

Настоящее исправление — это патч вашего ядра. Проверьте бюллетени безопасности вашего дистрибутива:

Пока вы ждёте (или если патчи для вашего дистрибутива ещё недоступны), добавьте уязвимые модули в чёрный список:

⚠️ Прежде чем это делать:

• Добавление esp4/esp6 в чёрный список сломает IPsec-туннели (strongSwan, Libreswan; WireGuard не затрагивается). Не применяйте это на VPN-шлюзах.
• Добавление rxrpc в чёрный список сломает клиентов распределённой файловой системы AFS. Почти никто этим не пользуется — но сначала проверьте.

Важно: если ваша система могла быть атакована до применения мер смягчения, эксплойт может модифицировать бинарные файлы в page cache, не касаясь диска. Инструменты контроля целостности файлов (Tripwire, AIDE), проверяющие контрольные суммы на диске, не увидят ничего подозрительного. Перезагрузка очищает page cache и восстанавливает состояние на диске.

Как это работает (краткая версия)

Обе ошибки находятся в быстрых путях дешифрования на месте в ядре. Когда сокетный буфер содержит страничные фрагменты, не принадлежащие ядру на правах частной собственности — например, страницы pipe, присоединённые через splice() или sendfile() — пути приёма ESP и RxRPC дешифруют напрямую поверх этих внешне поддерживаемых страниц, вместо того чтобы сначала копировать.

Атакующий может направить страницу из кэша /usr/bin/su (или любого другого читаемого файла) в один из этих путей дешифрования, используя свой собственный ключ, чтобы «расшифрованный вывод» был любыми байтами по его выбору. Ядро записывает эти байты прямо в кэшированную в памяти копию su. Файл на диске не затрагивается. Ядро никогда не помечает страницу как «грязную».

С этого момента каждый процесс, выполняющий su, запускает версию атакующего — до drop_caches или перезагрузки.

Вариант ESP (cac2661c53f3) и вариант RxRPC (2dc334f1a63a) используют один и тот же приёмник, но имеют разные предварительные условия, которые взаимно компенсируются, делая цепочку надёжной во всех основных конфигурациях.

Полное техническое описание см. в V4bel/dirtyfrag.

Хронология раскрытия

Авторство: Хёну Ким (@v4bel) за оригинальное исследование, раскрытие и PoC.

Отказ от ответственности

Только обнаружение. Применяйте к системам, на проверку которых у вас есть разрешение.