- 27,863
- 46
- 8 Ноя 2022
Атака меняет кэшированный образ setuid-программы, а файл на диске остаётся нетронутым.
В Linux нашли уязвимость, которая превращает обычного локального пользователя в root без изменения файлов на диске. Проверки целостности при такой атаке могут ничего не показать, потому что вредоносная правка живёт не в самом файле, а в его копии в памяти.
Уязвимость получила номер CVE-2026-46331 и неофициальное название pedit COW. Проблема скрывается в подсистеме traffic control, которая управляет сетевым трафиком в ядре Linux. Ошибка затрагивает действие act_pedit, позволяющее менять заголовки пакетов на лету. Red Hat оценила уязвимость как важную, а рабочий публичный эксплойт появился уже на следующий день после назначения CVE 16 июня.
Самый неприятный момент связан с механизмом атаки. Эксплойт не переписывает файл на диске и не оставляет привычного следа в бинарнике. Вместо прямой правки злоумышленник отравляет кэшированную в памяти копию setuid-root программы, например /bin/su, добавляет небольшой фрагмент кода и запускает изменённый образ с правами root. Файл на диске остаётся прежним, поэтому стандартная проверка целостности может сообщить, что всё чисто, пока злоумышленник уже получил root-оболочку.
Для атаки нужны два условия. В системе должен загружаться модуль act_pedit, а непривилегированные пользовательские пространства имён должны быть доступны обычным пользователям. В таком пространстве злоумышленник получает локальную сетевую возможность CAP_NET_ADMIN, достаточную для запуска уязвимого пути в ядре. На проверенных системах RHEL и Debian оба условия выполнялись.
Корень проблемы лежит в реализации copy-on-write. Инструмент tc может менять заголовки пакетов через действие pedit, а функция ядра tcf_pedit_act() должна сначала создать частную копию данных и только затем редактировать содержимое. Проверка допустимого диапазона записи проходила слишком рано, ещё до окончательного вычисления смещений. Некоторые правила pedit получают точное смещение только во время выполнения. В результате запись уходит за пределы приватной копии, и ядро меняет общую страницу page cache вместо отдельного буфера. Если такая страница относится к кэшированному файлу, в памяти портится образ файла.
По форме ошибка похожа на Dirty Pipe, Copy Fail, DirtyClone и Dirty Frag. Во всех случаях быстрый путь в ядре пишет в страницу памяти, которой ядро не владеет эксклюзивно, а удар принимает page cache. Новизна pedit COW в другом входе в атаку. Обычный пользователь может настроить действия tc внутри user namespace и получить нужную для эксплуатации CAP_NET_ADMIN без настоящих административных прав в основной системе.
Автор proof-of-concept сообщил об успешном повышении прав до root на RHEL 10 и Debian 13 trixie, где непривилегированные пользовательские пространства имён открыты по умолчанию. На Ubuntu 24.04 атаку пришлось проводить через профили AppArmor, которые всё ещё разрешают user namespaces. Ubuntu 26.04 по умолчанию блокирует такой путь, потому что профили AppArmor ограничивают непривилегированные пользовательские пространства имён, хотя само ядро остаётся уязвимым.
Исправления зависят от дистрибутива. Debian уже закрыл проблему в trixie через канал безопасности, но Debian 11 и 12 всё ещё числятся уязвимыми в исходном описании. Ubuntu по состоянию на 25 июня указывала поддерживаемые версии с 18.04 по 26.04 как уязвимые. Red Hat перечисляла среди затронутых RHEL 8, 9 и 10, а RHEL 7 в бюллетене не фигурировала.
Главная защита простая, нужно установить исправленное ядро и перезагрузить систему. В первую очередь патчи нужны серверам, где локальный пользователь не равен доверенному пользователю. Речь о многопользовательских хостах, CI/CD-раннерах, узлах Kubernetes, сборочных машинах, исследовательских стендах и учебных лабораториях.
Если быстро обновить ядро нельзя, цепочку эксплуатации можно разорвать двумя способами. На системах, где не нужны правила tc pedit, администратор может проверить загрузку act_pedit через lsmod | grep act_pedit и запретить дальнейшую загрузку модуля через правило install act_pedit /bin/true в /etc/modprobe.d/disable-act_pedit.conf. Второй вариант, отключить непривилегированные пользовательские пространства имён. Для RHEL используется user.max_user_namespaces=0, для Debian и Ubuntu, kernel.unprivileged_userns_clone=0. Такой шаг убирает локальную возможность, нужную эксплойту, но может сломать rootless-контейнеры, CI-песочницы и браузерные изоляции, поэтому менять параметр лучше после проверки на тестовой машине.
Из-за атаки на кэш памяти обычные проверки файлов могут не поймать компрометацию. Сброс page cache через echo 3 > /proc/sys/vm/drop_caches очищает испорченную копию в памяти, но не закрывает уже открытую root-оболочку. Если эксплойт мог сработать на хосте, машину надо рассматривать как скомпрометированную.
Показательная деталь связана с историей исправления. Патч попал в список рассылки netdev ещё в конце мая как обычное исправление повреждения данных. Эксплуатируемый смысл ошибки несколько недель лежал публично, без CVE и отдельного предупреждения о безопасности. CVE назначили после включения исправления 16 июня, а готовый proof-of-concept появился в течение суток. Для ошибок в page cache такой темп означает простую вещь, ждать правила для сканера слишком поздно.
В Linux нашли уязвимость, которая превращает обычного локального пользователя в root без изменения файлов на диске. Проверки целостности при такой атаке могут ничего не показать, потому что вредоносная правка живёт не в самом файле, а в его копии в памяти.
Уязвимость получила номер CVE-2026-46331 и неофициальное название pedit COW. Проблема скрывается в подсистеме traffic control, которая управляет сетевым трафиком в ядре Linux. Ошибка затрагивает действие act_pedit, позволяющее менять заголовки пакетов на лету. Red Hat оценила уязвимость как важную, а рабочий публичный эксплойт появился уже на следующий день после назначения CVE 16 июня.
Самый неприятный момент связан с механизмом атаки. Эксплойт не переписывает файл на диске и не оставляет привычного следа в бинарнике. Вместо прямой правки злоумышленник отравляет кэшированную в памяти копию setuid-root программы, например /bin/su, добавляет небольшой фрагмент кода и запускает изменённый образ с правами root. Файл на диске остаётся прежним, поэтому стандартная проверка целостности может сообщить, что всё чисто, пока злоумышленник уже получил root-оболочку.
Для атаки нужны два условия. В системе должен загружаться модуль act_pedit, а непривилегированные пользовательские пространства имён должны быть доступны обычным пользователям. В таком пространстве злоумышленник получает локальную сетевую возможность CAP_NET_ADMIN, достаточную для запуска уязвимого пути в ядре. На проверенных системах RHEL и Debian оба условия выполнялись.
Корень проблемы лежит в реализации copy-on-write. Инструмент tc может менять заголовки пакетов через действие pedit, а функция ядра tcf_pedit_act() должна сначала создать частную копию данных и только затем редактировать содержимое. Проверка допустимого диапазона записи проходила слишком рано, ещё до окончательного вычисления смещений. Некоторые правила pedit получают точное смещение только во время выполнения. В результате запись уходит за пределы приватной копии, и ядро меняет общую страницу page cache вместо отдельного буфера. Если такая страница относится к кэшированному файлу, в памяти портится образ файла.
По форме ошибка похожа на Dirty Pipe, Copy Fail, DirtyClone и Dirty Frag. Во всех случаях быстрый путь в ядре пишет в страницу памяти, которой ядро не владеет эксклюзивно, а удар принимает page cache. Новизна pedit COW в другом входе в атаку. Обычный пользователь может настроить действия tc внутри user namespace и получить нужную для эксплуатации CAP_NET_ADMIN без настоящих административных прав в основной системе.
Автор proof-of-concept сообщил об успешном повышении прав до root на RHEL 10 и Debian 13 trixie, где непривилегированные пользовательские пространства имён открыты по умолчанию. На Ubuntu 24.04 атаку пришлось проводить через профили AppArmor, которые всё ещё разрешают user namespaces. Ubuntu 26.04 по умолчанию блокирует такой путь, потому что профили AppArmor ограничивают непривилегированные пользовательские пространства имён, хотя само ядро остаётся уязвимым.
Исправления зависят от дистрибутива. Debian уже закрыл проблему в trixie через канал безопасности, но Debian 11 и 12 всё ещё числятся уязвимыми в исходном описании. Ubuntu по состоянию на 25 июня указывала поддерживаемые версии с 18.04 по 26.04 как уязвимые. Red Hat перечисляла среди затронутых RHEL 8, 9 и 10, а RHEL 7 в бюллетене не фигурировала.
Главная защита простая, нужно установить исправленное ядро и перезагрузить систему. В первую очередь патчи нужны серверам, где локальный пользователь не равен доверенному пользователю. Речь о многопользовательских хостах, CI/CD-раннерах, узлах Kubernetes, сборочных машинах, исследовательских стендах и учебных лабораториях.
Если быстро обновить ядро нельзя, цепочку эксплуатации можно разорвать двумя способами. На системах, где не нужны правила tc pedit, администратор может проверить загрузку act_pedit через lsmod | grep act_pedit и запретить дальнейшую загрузку модуля через правило install act_pedit /bin/true в /etc/modprobe.d/disable-act_pedit.conf. Второй вариант, отключить непривилегированные пользовательские пространства имён. Для RHEL используется user.max_user_namespaces=0, для Debian и Ubuntu, kernel.unprivileged_userns_clone=0. Такой шаг убирает локальную возможность, нужную эксплойту, но может сломать rootless-контейнеры, CI-песочницы и браузерные изоляции, поэтому менять параметр лучше после проверки на тестовой машине.
Из-за атаки на кэш памяти обычные проверки файлов могут не поймать компрометацию. Сброс page cache через echo 3 > /proc/sys/vm/drop_caches очищает испорченную копию в памяти, но не закрывает уже открытую root-оболочку. Если эксплойт мог сработать на хосте, машину надо рассматривать как скомпрометированную.
Показательная деталь связана с историей исправления. Патч попал в список рассылки netdev ещё в конце мая как обычное исправление повреждения данных. Эксплуатируемый смысл ошибки несколько недель лежал публично, без CVE и отдельного предупреждения о безопасности. CVE назначили после включения исправления 16 июня, а готовый proof-of-concept появился в течение суток. Для ошибок в page cache такой темп означает простую вещь, ждать правила для сканера слишком поздно.
- Источник новости
- www.securitylab.ru
