Уязвимость CIFSwitch в Linux, по данным исследователя, живет в коде с 2007 года и при удачном раскладе позволяет обычному локальному пользователю получить root. Для российских команд, у которых Linux стоит в серверном контуре, на рабочих станциях разработчиков или в тестовых средах, это не академическая история про «когда-нибудь»: проблема бьет по сочетанию ядра, cifs-utils и настроек безопасности, а значит проверять нужно не только версию ядра, но и реальную конфигурацию хоста.
О находке сообщает BleepingComputer. Речь идет о локальной уязвимости повышения привилегий, которую исследователь и инженер SpaceX по безопасности Асим Вилади Оглу Манизада назвал CIFSwitch. Проблема связана с подсистемой CIFS в ядре Linux и механизмом запроса ключей: если удаленная CIFS-шара использует Kerberos, ядро обращается к пользовательскому helper-процессу для аутентификации, а роль посредника выполняет набор утилит cifs-utils. В нормальном сценарии helper cifs.upcall запускается с root-правами и получает материалы Kerberos/SPNEGO. Ошибка в том, что ядро не проверяет, что запрос ключа типа cifs.spnego действительно пришел от CIFS-клиента ядра. Из-за этого непривилегированный пользователь может подделать такой запрос и заставить систему пройти штатный путь аутентификации уже на своих условиях.
Дальше начинается самое неприятное. Как описывает исследователь, root-процесс cifs.upcall доверяет полям запроса, которые считает сгенерированными ядром. Если атакующий подсовывает контролируемые значения, он может добиться переключения namespace, а затем спровоцировать обращение к Name Service Switch до сброса привилегий. На практике это открывает путь к загрузке вредоносного NSS-модуля и выполнению кода с правами root. Звучит не как «еще одна странная ошибка в редко используемой функции», а как вполне рабочая цепочка: есть доверенный root-helper, есть неподтвержденный источник запроса, есть PoC-эксплойт для проверки, что защита у вас не только на бумаге.
Важно, что уязвимость CIFSwitch не названа универсальной. Для эксплуатации нужны несколько условий сразу: уязвимое ядро, уязвимая версия cifs-utils, доступность user namespaces и такие политики SELinux или AppArmor, которые не ломают цепочку атаки. BleepingComputer приводит список дистрибутивов, которые исследователь подтвердил как уязвимые в конфигурации по умолчанию: Linux Mint 21.3 и 22.3, CentOS Stream 9, Rocky Linux 9, AlmaLinux 9, Kali Linux версий 2021.4–2026.1 и SLES 15 SP7. Дополнительно отмечается, что некоторые версии Ubuntu, Debian, Pop!_OS, openSUSE, Oracle Linux и Amazon Linux тоже могут оказаться уязвимыми, если установлен пакет cifs-utils. То есть формула «мы не из списка, значит все в порядке» здесь не работает.
Есть и обратная сторона: в ряде систем дефолтные политики безопасности уже мешают эксплуатации. В публикации перечислены Ubuntu 26.04, Fedora 40–44, CentOS Stream 10, Rocky Linux 10, SLES 16, AlmaLinux 10 и openSUSE Leap 16, где стандартные настройки SELinux или AppArmor блокируют атаку. Отдельно указано, что Amazon Linux 2, а также Kali Linux 2019.4 и 2020.4 вовсе не подвержены этой схеме, потому что их версии cifs-utils не содержат функциональность переключения namespace, на которой держится эксплуатация. Для эксплуатации это плохая новость, для админов хорошая: история снова показывает, что защитные механизмы уровня ОС иногда спасают даже тогда, когда уязвимый код все еще рядом.
Исправление уже есть: upstream-патч с коммитом 3da1fdf добавляет проверку происхождения запросов cifs.spnego. Но это как раз тот случай, когда надпись «patch available» мало что говорит бизнесу и эксплуатации. Конкретные версии ядра с этим исправлением будут отличаться от дистрибутива к дистрибутиву, а значит организациям придется смотреть не новости, а свои репозитории, advisory от вендора и фактическое состояние хостов. Если у вас парк на смеси Ubuntu, Rocky, Kali, SLES и кастомных образов для облака, инвентаризация здесь важнее красивых дашбордов: одна забытая машина с user namespaces и установленным cifs-utils может оказаться самым коротким путем к root внутри сегмента.
Практические рекомендации исследователя выглядят вполне приземленно. Если модуль CIFS не используется, его предлагают отключить или занести в blacklist. Если пакет cifs-utils не нужен, удалить. Если сценарии позволяют, стоит отключить непривилегированные user namespaces. Для разработчиков и DevOps-команд это неудобный, но полезный чек-лист: вспомнить, где вообще реально нужен доступ к SMB/CIFS, а где пакет годами лежит в базовом образе «на всякий случай». Для ИБ-команд вывод еще проще: локальное повышение привилегий на Linux давно перестало быть экзотикой для редких дистрибутивов и старых конфигураций. За последние месяцы BleepingComputer уже писал о серии схожих багов вроде Copy Fail, Dirty Frag, Fragnesia, DirtyDecrypt и PinTheft. Тренд неприятный, но понятный: атакующие все активнее работают не только по сети, но и по внутреннему устройству ОС, где один helper с root-правами и один небрежно проверенный запрос иногда значат больше, чем очередной perimeter security.
Уязвимость CIFSwitch интересна не только самой техникой эксплуатации, но и тем, как она ломает привычную уверенность в «локальном» риске. В инфраструктуре, где разработчики, CI-агенты, jump-хосты и сервисные аккаунты делят одну операционную реальность, локальный root часто быстро превращается в доступ к секретам, токенам и соседним системам. Поэтому главный вопрос теперь не в том, есть ли патч, а в том, сколько компаний действительно знают, где у них активны CIFS, cifs-utils и user namespaces. Детали исследования и ссылки на технический разбор с PoC собраны в публикации .