Компания Canonical опубликовала предварительные итоги независимого аудита безопасности инструментария uutils coreutils (Rust Coreutils), написанного на языке Rust и частично применяемого в Ubuntu вместо пакета GNU Coreutils. Аудит был выполнен компанией Zellic, имеющей опыт анализа уязвимостей в проектах на языке Rust. В ходе проверки было выявлено 113 проблем с безопасностью.
В настоящее время уже доступен отчёт (PDF, 156 страниц) с результатами первого этапа аудита, охватывающего наиболее важные утилиты из набора uutils. На первом этапе, который был проведён с декабря 2025 по январь 2026 года, было выявлено 73 уязвимости, из которых 7 отмечены как критические, 11 - опасные, 29 - средней опасности и 26 - неопасные.
Второй этап аудита был проведён с февраля по март и охватывал второстепенные утилиты, не проверенные на первом этапе. На втором этапе было найдено 40 уязвимостей, опасность которых пока не детализируется (отчёт планируют опубликовать позднее). Информация о всех выявленных проблемах уже передана разработчикам uutils и большая часть уязвимостей была устранена в выпусках uutils 0.5-0.8 без лишней огласки и пометки связи вносимых исправлений с устранением уязвмостей.
Пакет rust-coreutils был включён по умолчанию в осеннем выпуске Ubuntu 25.10, но с учётом выявленных в ходе аудита проблем в LTS-ветке Ubuntu 26.04 возвращены утилиты cp, mv и rm из набора GNU Coreutils. Отмечается, что по состоянию на 22 апреля в данных утилитах остаётся не исправлено 8 известных состояний гонки. Остальные утилиты задействованы из выпуска rust-coreutils 0.8.0. В Ubuntu 26.10 разработчики намерены полностью перейти на rust-coreutils.
Уязвимости в системных утилитах опасны тем, что они используется в скриптах, запускаемых с правами root. Например, устранённая в выпуске uutils coreutils 0.3.0 уязвимость в утилите rm могла быть эксплуатирована при ежедневном запуске из cron скрипта /etc/cron.daily/apport, который выполняется с правами root и рекурсивно удаляет содержимое каталога /var/crash, доступного на запись всем пользователям в системе.
Среди уязвимостей, помеченных в первом отчёте критическими:
- Уязвимость в утилите chroot, вызванная обработкой опции “–userspec” после вызова chroot(), но до сброса привилегий. На системах с glibc резолвинг имён через функцию getpwnam() приводит к чтению файла /etc/nsswitch.conf, применяемого в NSS (Name Service Switch), и динамической загрузке указанных в нём библиотек с модулями NSS (libnss_*.so.2). Так как до обработки NSS выполяется вызов chroot() файл /etc/nsswitch.conf загружается относительно нового корня, но NSS-библиотеки загружаются до сброса привилегий. Если пользователь имеет доступ на запись к новому корню, то он может подставить свои NSS-библиотеки и добиться выполнения кода с правами root.
- Изменение прав доступа к файлу после сбоя создания именованного канала (FIFO) утилитой mkfifo - если указать в качестве аргумента существующий файл, то mkfifo вернёт ошибку, но при этом аварийно не завершит работу, а выполнит вызов set_permissions() и изменит права доступа к существующему файлу. С учётом umask 022 уязвимость позволяет поменять права доступа к файлу на 644 (rw-r-r-) и получить доступ к файлам, для которых не было разрешено чтение.
- Обход ограничений “–preserve-root” в утилите chmod, запрещающих выполнение рекурсивных операций относительно корня ФС. Уязвимость (CVE-2026-35338) вызвана тем, что в коде проверялось только точное совпадение пути с “/” и не выполнялась канонизация файлового пути. Для обхода проверки достаточно использовать путь вида “/…/” или символическую ссылку на корень. Уязвимость опасна тем, что при возможности подставить свой путь в системный скрипт вызывающий команду chmod, можно добиться рекурсивного изменения прав доступа для всех файлов в ФС.
- В утилите rm допускалась обработка любых сокращений опции “–no-preserve-root” (“–n”, “–no”, “–no-p”, “–no-pres” и т.п.) для отключения защиты от выполнение рекурсивной операции с корнем (например, можно указать “rm -rf --n /” и удалить по ошибке все данные. В GNU Coreutils подобные сокращённые опции запрещены.
- Обход ограничений “–preserve-root” в утилите rm, запрещающих выполнение рекурсивных операций относительно корня ФС, через подстановку символической ссылки на “/”.
- Отсутствие полноценной защиты от указания каталогов, начинающихся с точки. Например, при выполнении “rm -rf .” утилита выведет ошибку, но при указании “rm -rf ./” или “rm -rf .///” молча удалит текущий каталог.
- Ошибка в коде разбора аргументов утилиты kill позволяет отправить сигнал всем процессам в системе при указании идентификатора процесса “-1” (kill -1).
В остальном большая часть уязвимостей относится к классу TOCTOU (Time-Of-Check-To-Time-Of-Use), подразумевающему наличие состояния гонки, позволяющего изменить данные в момент после проверки корректности информации, но до выполнения операции с ними, например, подменить файл на символическую ссылку в момент между завершением проверки и началом выполнения операции. В контексте использования утилит cp и mv в системных скриптах, запускаемых с правами root, подобные уязвимости позволяют скопировать или перезаписать произвольные файлы.
<<<
В остальном большая часть уязвимостей относится к классу TOCTOU (Time-Of-Check-To-Time-Of-Use), подразумевающему наличие состояния гонки
Мне где-то кто-то давно затирал, что в Rust такого быть не может.
«Мне где-то кто-то давно затирал, что в Rust такого быть не может.» Так это не косяк языка. «TOCTOU (Time-Of-Check-To-Time-Of-Use)» Сраный ЧатГПТ в деталях объясняет в чём проблема и как это фиксить, буквально парой строчек. Не фанат нейродрочева, но по-моему, это как раз тот случай, когда инструменты автоматизации (в том числе нейронки) могли бы найти и помочь пофиксить большинство проблем, если бы разрабы нашли выход из vim и воспользовались современными средствами разработки.
Сраный ЧатГПТ в деталях объясняет в чём проблема и как это фиксить, буквально парой строчек.
И сишные уязвимости он тоже фиксит тогда.
kek, сугоме какой язык ни дай, сраное решето выйдет.
В моих программах на C дыр нет!
В моих тоже, потому что я не пишу на C.
Прочитаи заголовок новости.
Прочитаи заголовок новости.
Прочитал. Не собираюсь писать на C, не убедила меня эта новость.
А на чем ты пишешь?
А на чем ты пишешь?
go
Программы на Си хотя бы собрать можно оффлайн, в отличие от твоих поделок.
Программы на Си хотя бы собрать можно оффлайн, в отличие от твоих поделок.
В чём проблема предварительно скачать библиотеки?
вот я тоже думал что с моим образованием надо стать программистом или электронщиком. Но подумал подумал хорошо уже в процессе натурализации и решил не связываться с программированием. Хотя уважаю тех кто это умеет. У нас в конторе всего один айтишники этакое забитое работой существо и мониторов перед ним целых пять. Многостаночник наверное.
Вернись в Хохланд свой уже и не мешай местным датчанам жить!
и мониторов перед ним целых пять. Многостаночник наверное.
Это вкусовщина.
Ты на пыхе говнокодишь, не пизди
Я пишу и на PHP, и на Си.
Царь бы тебя за такое…
Ты как турбопатриот обязан говнокодить на православном 1С
Зачем? Он объективно хуже.
Если интегрировать systemd-verifyaged в Rust, тогда он станет ещё безопаснее?






