Критическая уязвимость в sudo позволяет запустить любую команду как root

Критическая уязвимость в sudo позволяет запустить любую команду как root

Критическая уязвимость в sudo позволяет запустить любую команду как root

Опубликован PoC-код для уязвимости в sudo, позволяющей с помощью опции -R (--chroot) обойти системные ограничения и выполнить вредоносный код с правами суперпользователя. Патч включен в состав обновления 1.9.17p1.

Появившаяся с выходом сборки sudo 1.9.14 функция chroot() создает изолированную среду, в которой текущий и дочерние процессы могут работать, не имея доступа к объектам и ресурсам за пределами указанного корневого каталога.

Соответствующая команда выполняется на уровне root. Ее использование определяется правилами, прописанными в файле /etc/sudoers.

Уязвимость повышения привилегий CVE-2025-32463 (9,3 балла по CVSS) возникла из-за того, что при изменении корневого каталога sudo начинает резолвить пути к файлам, не завершив проверку параметров настройки в sudoers.

В результате у злоумышленников появилась возможность с помощью этой утилиты протащить в систему стороннюю библиотеку общего пользования, создав фейковый /etc/nsswitch.conf.

Уязвимости подвержены sudo версий с 1.9.14 по 1.9.17 включительно. Патч вышел в прошлом месяце в составе сборки 1.9.17p1; он откатывает изменения, привнесенные в 1.9.14, с пометкой, что использовать chroot не рекомендуется.

По словам разработчиков, со следующим выпуском sudo от неудачно реализованной и редко используемой опции не останется и следа.

Подпишитесь на новости

1,8 ТБ и вагон ошибок: как выгрузка с Яндекс Диска превратилась в квест

Пользователь «Яндекс Диска» решил сделать резервную копию 1,8 ТБ файлов, а также примерно 160 ГБ фотографий и получил приключение с ошибками API, зависшими загрузками и собственными скриптами.

По его словам, после октябрьских проблем с дата-центрами привычное скачивание папок через веб-интерфейс стало недоступно.

Подробности инженер Сергей Терёхин, известный как KenGuru66, описал  в собственном разборе на Хабре.

План был такой: rclone, сервер в Нидерландах, копия в Google Drive. Но стандартная аутентификация позволяла получить сведения о диске, а обращения к файлам возвращали ошибку 410. Доступ удалось наладить с другим OAuth-токеном.

Фотографии из безлимитной автозагрузки добавили веселья: для копирования через выбранный API их пришлось переместить в обычную папку. После этого они начали занимать место в тарифе. Более 30 тысяч снимков переносились около шести часов.

В выборке из 300 случайных файлов автор смог получить начало только 146. По важной папке с документами он скопировал и проверил по MD5 2315 файлов; ещё 3079 на момент публикации оставались недоступны.

Потерю данных автор не утверждает, он продолжает повторные загрузки. Скрипты опубликованы на GitHub.

RSS: Новости на портале Anti-Malware.ru