OVSwrap: путь к root через Open vSwitch

OVSwrap, зарегистрированная как CVE-2026-64531 с оценкой CVSS 7.8, представляет собой ошибку повреждения памяти в модуле datapath Open vSwitch ядра Linux. Пользовательский демон ovs-vswitchd к ней отношения не имеет. Исследователь безопасности Asim Manizada раскрыл уязвимость 28 июля 2026 года и охарактеризовал её как повреждение памяти с «надёжностью уровня логической ошибки». Обычный локальный пользователь может получить root на многих дистрибутивах с настройками по умолчанию. Особенно опасны общие серверы с несколькими пользователями или сайтами, недоверенными задачами и контейнерами, которым доступны нужные сетевые пространства имён.
OVSwrap: путь к root через Open vSwitch
Изображение носит иллюстративный характер

Для обычной учётной записи путь к уязвимому коду открывается, если доступен OVS kernel datapath и разрешены непривилегированные пользовательские пространства имён. Команда unshare -Urn создаёт частные user- и network namespace, где пользователь получает CAP_NET_ADMIN и может обратиться к установке потоков OVS. По словам Manizada, атакующему не нужны «существующий мост OVS, запущенный ovs-vswitchd или CAP_NET_ADMIN на уровне хоста». Отсутствие openvswitch в выводе lsmod ничего не гарантирует: если модуль установлен, разрешение имени его семейства Generic Netlink способно вызвать автоматическую загрузку.
Причина OVSwrap связана с хранением сгенерированных действий потока в атрибутах Netlink. Поле nla_len имеет ширину 16 бит, поэтому один вложенный атрибут не может корректно описать размер свыше 65 535 байт. Небезопасное присваивание длины прожило в коде около 13 лет, но его сдерживал отдельный лимит общего потока действий в 32 КиБ. В марте 2025 года ограничение убрали: оно порождало трудно предсказуемые сбои, в том числе в крупных инсталляциях OpenStack. При обсуждении коммита разбирали надёжность и ошибки, заметные пользователям, но последствия исчезновения защитного лимита для безопасности остались без внимания.
Переполнение вызывается действием CLONE с сотнями вложенных conntrack-действий. На x86-64 каждое такое действие разворачивается ядром до 164 байт, общий размер пересекает границу 65 535 байт, а запись в nla_len обрезается до 16 бит. Позднее ядро доверяет искажённой длине и продолжает разбор уже внутри подготовленных атакующим данных conntrack, где размещены поддельные действия OVS. Точка, в которую попадает парсер, вычисляется заранее и остаётся в том же непрерывном буфере. Подгонять размещение объектов в куче, то есть заниматься heap grooming, эксплойту не требуется.
Из переполнения получаются три примитива. Поддельное действие OUTPUT раскрывает указатель ядра; сфальсифицированное туннельное действие SET позволяет читать выбранные участки памяти; освобождение поддельного указателя tun_dst даёт управляемое уменьшение значения по нужному адресу. Затем эксплойт находит учётные данные процесса хоста и меняет их. На современных ядрах он уменьшает fsuid и fsgid до нуля, что в данном случае соответствует владельцу и группе root.
Manizada сообщил об ошибке 19 июня 2026 года сопровождающим OVS и ещё одному получателю, имя которого в опубликованной хронологии отсутствует. Исправление появилось в стабильных ветках Linux 24 июля, а публичное раскрытие состоялось 28 июля. Первые исправленные upstream-выпуски: 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40 и 7.1.5. Завершившие жизненный цикл серии 6.13, 6.14, 6.15, 6.16, 6.17, 6.19 и 7.0 стабильных upstream-патчей не получат. Сравнивать только номера версий ненадёжно: дистрибутивы применяют обратные переносы исправлений, собственные изменения и наборы патчей, поэтому проверять статус следует в трекере безопасности конкретного поставщика.
Публичный proof of concept требует поддержки conntrack в Open vSwitch, FTP-помощника conntrack и установленного sudo. При успехе он повреждает действующие учётные данные ядра, меняет /etc/sudoers.d либо /etc/sudoers и запускает оболочку root. После него остаются процессы и состояние OVS: очистка намеренно не выполняется, поскольку демонтаж созданных объектов может оказаться небезопасным. Авторы прямо называют PoC разрушительным, использовать его как безобидный сканер нельзя. Репозиторий содержит готовые записи примерно для 800 точных сборок ядра x86-64, а для отсутствующих сборок пытается вычислить нужные сведения по символам ядра и данным BTF.
Неисчерпывающая тестовая матрица подтвердила эксплуатацию с настройками по умолчанию в AlmaLinux 9 и 10, Alpine Linux 3.22, 3.23 и 3.24, Amazon Linux 2023, Arch Linux, CentOS Stream 9 и 10, Debian 12 и 13, Fedora 42, 43 и 44, Gentoo, Kali Linux 2026.1, Linux Mint 22.3, NixOS, openSUSE Tumbleweed, Pop!_OS, Rocky Linux 9 и 10, Ubuntu 22.04. В испытанной Ubuntu 24.04 AppArmor блокировал прямое создание пространств имён, однако запасной запуск aa-exec -p trinity, включённый в PoC, возвращал доступ к уязвимому пути. Штатная Ubuntu 26.04 закрывала маршрут для обычного пользователя; после отключения ограничения AppArmor на пользовательские пространства имён система становилась уязвимой.
Amazon Linux 2, Debian 11, Rocky Linux 8 и Ubuntu 20.04 сохранили старые ветви кода и в тестах не поддались атаке описанным способом. Это не доказывает отсутствие других рисков Open vSwitch. CloudLinux разбирает более житейский сценарий: локальным пользователем может оказаться злоумышленник, ранее захвативший один сайт через постороннюю дыру. OVSwrap превращает инцидент в пределах одной учётной записи или сайта в компрометацию всего сервера. Та же проблема касается процессов и контейнеров, уже имеющих CAP_NET_ADMIN над контролируемым ими network namespace; контейнерный вариант Manizada считал теоретически достижимым, но опубликованный PoC его не показывал.
Основная мера защиты — установить исправленное ядро поставщика и сверить его статус с vendor security tracker. Если Open vSwitch не используется, будущую загрузку модуля можно запретить командой echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf. Файл /etc/modprobe.d/ovswrap.conf не удаляет модуль, уже находящийся в памяти: openvswitch придётся выгрузить либо перезагрузить машину. Запрет непривилегированных user namespace закрывает вариант с unshare -Urn, но не защищает от процесса или контейнера с подходящим CAP_NET_ADMIN. Для систем, где одновременно необходимы OVS и пользовательские с сетевыми пространствами имён, в репозитории PoC предусмотрен аварийный BPF-фильтр.


Новое на сайте

Ссылка