Sudo по праву считается одним из важнейших инструментов в арсенале системных администраторов и пользователей UNIX-подобных систем. Его основная задача – предоставить делегированные привилегии для выполнения команд с правами других пользователей, чаще всего – с правами суперпользователя root. В основе Sudo лежит продуманный механизм управления доступом, который задаётся через конфигурационный файл sudoers. Этот файл определяет, кто и с какими правами может выполнять определённые команды и на каких хостах. Однако недавняя уязвимость, связанная с использованием опции -h (--host), выявила серьезные риски для безопасности систем, позволяя злоумышленникам получить локальное повышение привилегий даже при ограниченных правах.
В данной статье рассмотрим сущность уязвимости, её причины, влияние на безопасность и пути устранения проблемы. История и назначение опции host в sudo Опция -h или --host в sudo была разработана с определённой целью: позволить пользователю просматривать свои возможности sudo, но не на текущем хосте, а на удаленном, указанном им в параметре. Это актуально в больших корпоративных сетях, где один и тот же пользователь может иметь разные права на разных машинах, а системный администратор хочет быстро проверить настройки без необходимости подключения к каждому узлу. Изначально функция задумывалась исключительно для использования с опцией -l или --list, которая выводит список команд, доступных пользователю. В таком контексте указание другого хоста позволяет получить информацию об условиях работы sudo на той машине.
Однако реализованная логика обработки этого параметра оказалась далеке от идеала, что и привело к серьезной уязвимости. Суть уязвимости и её технические детали Основная проблема в том, что опция --host не была ограничена только возможностью вывода списка привилегий. Она оказалась применимой также при попытке запуска команд через sudo или когда пользователь редактировал файлы с использованием sudoedit. В итоге hostname, который должен был использоваться при проверке правил, теперь можно было подделать, указав произвольное имя – любой хост в правиле sudoers, а не только текущий. Особенность работы sudo заключается в том, что правила доступа в sudoers могут иметь формат с указанием имени хоста, на котором эти права действуют.
Таким образом, при работе sudo происходит проверка соответствия имени текущего хоста имени в правиле и имени пользователя, который пытается выполнить команду. Если все условия соблюдены – пользователю разрешается выполнение. Благодаря багу эта логика была нарушена: hostname, используемый в проверке, теперь мог быть подменён пользователем, что делало поле hostname в sudoers просто формальностью, и служило лишь для внешнего контроля, который легко обходился. Например, правило, в котором права пользователя alice были ограничены хостом cerebus, переставало иметь смысл. Пользователь alice мог запустить команду на другой машине, например hades, указав параметр --host cerebus.
Тогда проверка sudoers считала, что alice работает на cerebus и разрешала выполнение всех команд, если таковые были прописаны для alice на cerebus. В результате пользователь, который не имел права запускать sudo на hades, мог сделать это, указав другой хост. Этот баг присутствовал в версиях Sudo начиная с 1.8.8 и по 1.
9.17 включительно и был зарегистрирован в базе уязвимостей как CVE-2025-32462. Почему этот баг так опасен и в каких системах он актуален Основная опасность уязвимости заключается в возможности локального повышения привилегий. Злоумышленник, имеющий обычный пользовательский аккаунт, мог получить права root и выполнить опасные команды, обойти системы контроля и безопасности. Особенно это касается крупных организаций, где одним из способов управления доступом является централизованное распространение единого sudoers файла на множество серверов.
Такие sudoers могут содержать правила с указанием конкретных хостов, чтобы разграничить права между машинами. Для них уязвимость становится мощным вектором атаки. Аналогично риск присутствует и для систем, где sudoers хранится в LDAP или SSSD, где разграничение прав тоже может учитывать имя хоста. При этом пользователи, у которых нет доступа на текущей машине, могут злоупотребить багом для обхода ограничений. Следствия для безопасности и потенциальные угрозы Злоумышленник, получивший root-права, может полностью контролировать систему: устанавливать вредоносное ПО, удалять логи, создавать скрытые учетные записи, перехватывать коммуникации.
Более того, поскольку баг использует штатный механизм sudo, его эксплуатации крайне сложно быстро обнаружить в журналах аудита — команды будут выполнены через sudo, что на первый взгляд легитимно. Таким образом, потенциальные последствия можно считать критическими: скомпрометированная инфраструктура, утечка данных, долгая и сложная попытка восстановления контроля над системой. Как выявить уязвимость на своей системе Определить, подвержена ли система данной уязвимости достаточно просто. Необходимо проверить версию установленного sudo. Если версия находится в диапазоне от 1.
8.8 до 1.9.17 включительно, существует риск эксплойта. Помимо версии важно проверить конфигурацию sudoers.
Наличие в правилах хостовых ограничений, отличных от ALL, является маркером потенциальной опасности. Также стоит протестировать возможность запуска команд с параметром -h, пройдя минимум проверки, чтобы понять, возможна ли подмена имени хоста при выполнении sudo и sudoedit. Современные средства аудита и мониторинга безопасности могут помочь отследить подозрительные вызовы sudo с необычными параметрами, однако без автоматических механизмов контроля такая атака может остаться незамеченной. Рекомендации по устранению и защите от уязвимости Лучший и самый надёжный способ – обновить sudo до версии 1.9.
17p1 или выше, где эта ошибка исправлена. Обновление устраняет возможность использования параметра -h для выполнения команд вне текущего хоста. Если сразу обновить нельзя, следует временно ограничить использование sudo теми правилами, в которых указаны конкретные имена хостов, либо вообще воздержаться от использования параметра -h в рабочих процессах пользователей. В качестве превентивной меры рекомендуется пересмотреть архитектуру управления правами, чтобы минимизировать возможность подобного рода ошибок и повышать общий уровень безопасности. Важно регулярно обновлять системное программное обеспечение и компоненты, а также использовать средства автоматического анализа конфигураций на предмет уязвимостей.
