Была опубликована информация о новая критическая уязвимость что было обнаружено в утилите Sudo (наиболее широко используемый инструмент управления привилегиями в Linux).
Обозначено как CVE-2025-32463, эта ошибка позволяет любому непривилегированному локальному пользователю выполнять команды с правами root, даже если он не указан в конфигурации sudoers. Уязвимость была подтверждена в популярных дистрибутивах, таких как Ubuntu 24.04 и Fedora 41, и затрагивала их конфигурацию по умолчанию.
Источник проблемы кроется в опции –chroot (-R). от Судо, который позволяет запускать команды в изолированной среде файловой системыПри использовании этой опции Sudo меняет корневой каталог на указанный пользователем. Опасность заключается в том, что при этом Sudo загружает файл /etc/nsswitch.conf из chroot-окружения, а не из исходной системы.
Конфигурация Sudo по умолчанию уязвима. Хотя уязвимость влияет на функциональность chroot Sudo, она не требует определения правил Sudo для пользователя. Таким образом, любой непривилегированный локальный пользователь может повысить свои привилегии до уровня root, если установлена уязвимая версия. Известно, что следующие версии уязвимы. Примечание: не все версии из этого диапазона были протестированы.
Это открывает возможность для изобретательной атаки.: Если пользователь создаст собственную среду chroot и включит в неё изменённый файл nsswitch.conf, он может заставить систему загрузить пользовательские общие библиотеки, расположенные в этой среде. NSS (Переключатель службы имени) выполняет код перед отказом от привилегий rootзлоумышленнику удается запустить свой вредоносный код с привилегиями суперпользователя.
CVE-2025-32463: Доказательство концепции и технические подробности
Эксплуатация этого Уязвимость была продемонстрирована с помощью эксплойта в Bash который использует пользовательскую общую библиотеку и измененный файл конфигурации. При запуске sudo -R вут вут В этой среде система загружает библиотеку с правами root., что приводит к прямому повышению привилегий.
Хотяchroot обычно используется для ограничения доступа к файловой системе, как это происходит на FTP или SFTP серверах, Это не было разработано как мера безопасности.На самом деле, само руководство Linux предупреждает: chroot() изменяет только корневой каталог процесса, но не предотвращает опасные вызовы и не обеспечивает реальной изоляции.
В Sudo опция -R переключает пользователя в режим root перед выполнением команды, что может быть полезно в определенных сценариях, но также крайне рискованно, если непривилегированным пользователям разрешено определять среду.
Эта атака была проверена в версиях Sudo с 1.9.14 по 1.9.17., хотя есть подозрение, что это может повлиять на версию 1.8.33. Однако более старые версии (≤ 1.8.32) не подвержены уязвимости, поскольку в них не реализована функция chroot.
Другая связанная уязвимость: CVE-2025-32462
La Обновление, устраняющее эту проблему, также устраняет вторую уязвимость., идентифицированный как CVE-2025-32462, которая позволяет обходить ограничения хоста в sudoers.
Эта ошибка Это происходит, когда пользователь использует опцию –host. (-h) не только перечисляет правила привилегий, но и выполняет команды, что не предусмотрено. Если файл конфигурации содержит правила вроде testuser testhost = ALL, пользователь может выполнить команду sudo -h testhost для выполнения команд root на любом хосте, тем самым обходя ограничения.
Однако эта вторая ошибка Это влияет только на пользователей, которые уже являются участниками sudoers и чья конкретная конфигурация включает ограничения хоста..
Какие дистрибутивы затронуты?
Уязвимость подтверждена в:
- Ubuntu 24.04.1 с Sudo 1.9.15p5 и 1.9.16p2
- Fedora 41 с Sudo 1.9.15p5
Лас- Уязвимые версии находятся в диапазоне от 1.9.14 до 1.9.17, Важно отметить, что опция chroot устарела, начиная с версии Sudo 1.9.17p1. Поэтому её использование в производственных средах больше не рекомендуется.
Что рекомендуется делать?
Исследовательская группа Stratascale рекомендовала следующие действия:
- Обновите Sudo до версии 1.9.17p1 или выше.
- Избегайте использования параметра chroot, поскольку его функциональность устарела по соображениям безопасности.
- Проверьте использование runchroot= или аналогичных директив в /etc/sudoers и в файлах внутри /etc/sudoers.d.
- Проверьте системные журналы на наличие записей Sudo, использующих CHROOT=.
- Используйте такие инструменты, как ldapsearch, если ваши правила sudoers хранятся в LDAP.
Наконец, если вы хотите узнать больше об этом, вы можете ознакомиться с подробностями в по следующей ссылке.