LINUX.ORG.RU

В Rust Coreutils выявлено 113 уязвимостей. В Ubuntu 26.04 возвращены cp, mv и rm из GNU Coreutils

 , ,


1

5

Компания Canonical опубликовала предварительные итоги внешнего аудита безопасности инструментария uutils coreutils (Rust Coreutils), написанного на языке Rust и частично применяемого в Ubuntu вместо пакета GNU Coreutils. Аудит был выполнен компанией Zellic, имеющей опыт анализа уязвимостей в проектах на языке Rust. В ходе проверки было выявлено 113 проблем с безопасностью.

В настоящее время уже доступен отчёт с результатами первого этапа аудита, охватывающего наиболее важные утилиты из набора uutils. На первом этапе, который был проведён с декабря 2025 по январь 2026 года, было выявлено 73 уязвимости, из которых 7 отмечены как критические, 11 - опасные, 29 - средней опасности и 26 - неопасные.

Информация о всех выявленных проблемах уже передана разработчикам 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).

>>> Источник

★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 2)
Ответ на: комментарий от I-Love-Microsoft

Ответ очевиден. Эти инструменты обслуживают один конкретный домен. Как, например эти инструменты позволяют обнаруживать ошибки возникающие при пониженном или повышенном напряжении питания? При воздействии наводок на сигнальные выводы? Или может радиации? Вот и в расте, есть боров и он закрывает конкретный домен ошибок. Но он понятия не имеет о том что там в системах с libc6 делает nss

cobold ★★★★★
()
Ответ на: комментарий от unixnik

Кто они? Разрабы на расте хотят набить руку и получить строчку в резюме, вот написал то-то на расте. Промышленно эксплуатируется. Бизнесу надо показать кастомерам и правительствам в том числе, прогресс по усилению безопасности, так как это сейчас одна из точек продаж

cobold ★★★★★
()
Ответ на: комментарий от BceM_IIpuBeT

Когда человека навсегда исключат из цепочки производства кода. Даже из самого начала: пожелания что и как должно быть. Наш строгий, но великий и справедливый повелитель - Искусственный Интеллект 1.0 будет сам знать что показывать кому и делать налету. И не удет больше багов, не будет уязвимостей.

LightDiver ★★★★★
()
Ответ на: комментарий от BceM_IIpuBeT

Практика показывает что абсолютная безопасность скорее не достижима. А так уязвимости будут продолжать находить и фиксить, правда со временем все меньше. Думаю лет за 5 растовые утилиты стабилизируют

cobold ★★★★★
()
Ответ на: комментарий от zabbal

Про MISRA очень хорошо знаю, но это очень строгий стандарт, знаю много других подобных стандартов в разных отраслях. И это чистая правда, существуют даже таблицы кратности трудоемкости по закрытию того или иного уровня стандарта, а у реализуемых подсистем и блоков есть свои требования к минимальному уровню

Я не против раста хоть и не пишу на нем. Безопасный язык хорошо, возможно однажды появится какой то инструмент или методология для удешевления создания очень надежного безопасного софта

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от LightDiver

Когда человека навсегда исключат из цепочки производства кода. Даже из самого начала: пожелания что и как должно быть. Наш строгий, но великий и справедливый повелитель - Искусственный Интеллект 1.0 будет сам знать что показывать кому и делать налету. И не удет больше багов, не будет уязвимостей.

Ну, понимаешь, в чем дело. Тот «ИИ», который есть сейчас никогда не сможет стать тем самым ИИ 1.0, про который ты говоришь.

То, что ты имеешь в виду, это самообучающиеся системы ИИ. Но они в зачаточном состоянии. А тот «ИИ», что существует - базируется на уже полученных человеческих знаниях. В том числе - человеческих-же ошибках. Сюда-же можно добавить, что «ИИ» выдает вероятностный результат. А вчитавшись в условия поставки систем вроде копилот (а он базируется на чат-гпт), ты узнаешь, что они поставляются в развлекательных целях.

DrRulez ★★★★★
()
Ответ на: комментарий от DrRulez

Опасайся не того ИИ, что притворяется умным. Опасайся того, который притворяется глупым.

LightDiver ★★★★★
()

Удивительно что так много усилий нужно для казалось бы элементарных утилит. Хотя, если честно, представить не могу никого кроме новичка, желавшего отточить свои навыки, кто мог бы начать это всерьёз делать.

neumond ★★
()

Обыватели. Главное ищут эти расты, в эти расты туда влезают в молодые годы, а потом говорят: «Вот это да, говорит, вот это, говорит, погорел, вот это даже не рассчитывал!» Я говорю: за всё надо платить, причём по большому счёту. Ржавая зараза, через агриковский комбинат…

PantalonSeptRoubles
()
Ответ на: комментарий от I-Love-Microsoft

возможно однажды появится какой то инструмент или методология для удешевления создания очень надежного безопасного софта

https://mistral.ai/news/leanstral - тоже на это надеюсь.

zabbal ★★★★☆
()
Ответ на: комментарий от BceM_IIpuBeT

Ну так безопасность когда настанет?

У тебя? Никогда. Как справедливо отметили выше по треду

помимо использования «безопасного» язычка, нужно еще иметь мозги

zabbal ★★★★☆
()
Ответ на: комментарий от BceM_IIpuBeT

а код на Rust - останется

Он прокиснет после очередного amazing обновления.

прокиснет после очередного amazing обновления — это про зиг. Код на раст — blazing fast, не надо ему чужие эпитеты приписывать.

sarumeister
()

Ну, пусть даже там присутствует сейчас «113 багозвимостей»… только что это меняет?? — Упдэйтер переключил с багнутых утилит на стабильные, как в кино — компьютер починился сам.

Set440 ★★
()
Ответ на: комментарий от kaldeon

надёжные и стабильные дистры вроде Арч

Это сарказм, да?

mittorn ★★★★★
()
Ответ на: комментарий от wandrien

Когда убунта скатилась настолько, что... это становится правдой

mittorn ★★★★★
()

Когда вы устраняете повреждения памяти, то внезапно выясняется, что Rust совершенно никак не помогает вам устранять остальные типы ошибок. А они есть.

byko3y ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

Братцы, а ведь нам говорили, что если писать без unsafe, то гонок не будет.

Это не те гонки. Помимо unsafe доступа к памяти есть целая куча других классов гонок.

Я ещё с самого начала говорил, что чем больше Rust использовать на практике, тем больше есть говна и понимать, что memory safety — это даже не полововина проблем в разработке... но будет уже поздно. Почему я и пишу, что Rust не столько плохой, сколько посредственный и заметно хуже, чем системный ЯП мог бы быть. Неспроста люди создают столько альтернатив.

byko3y ★★★★★
()
Ответ на: комментарий от LightDiver

Когда вы устраняете повреждения памяти, то внезапно выясняется, что Rust совершенно никак не помогает вам устранять остальные типы ошибок. А они есть.

А си?

Как я недавно иронизировал в рабочей переписке «в языке Си не нужны проверки при компиляции, потому что программисты на Си сразу пишут код без багов». Причина, почему C++ вообще кто-то в принципе рассматривал, заключалась в том, что язык С запредельно плох. Даже по сравнению с ассемблерами того времени это был шаг назад. Си получил распространение как бесплатная газетка в придачу к юниксу.

Но из-за совместимости с Си новый C++ получился как повязка на гнойную рану — снаружи вроде причёсан, но внутри всё та же самая срань.

Именно эту новую проблему попытались решить разрабы Rust, забыв про важный момент — ни в коем случае нельзя допускать крестовиков к разработке нового ЯП. Потому что иначе будет то, что мы видим сейчас ­— ЯП, который повторил большую часть недостатков C++: медленную компиляцию, неоправданную усложнённость и потому ужасную читаемость, однозадачную-однопоточную модель данных.

Растовики пытаются победить говно, которое индустрия сама себе насрала на голову. Си плох, но по итогу один сорт говна заменяют на аналогичный.

byko3y ★★★★★
()
Ответ на: комментарий от LightDiver

А если сравнивать с альтернативой и если брать хорошее - раст хорош только memory safety и все?

Да, Rust — это memory safety как самоцель. Не смей спрашивать у растовика «а зачем тебе вообще эта memory safety?». Ну типа memory safety сама по себе биткоины не намайнит, базы данных не организует. Для многих применений memory safety вообще не является проблемой.

Давай возьмём элементарный пример: я делаю высоконагруженный сервер; в нём происходит переполненниые целого числа в одном из воркеров — как дальше жить этому серверу? Если у него был взят мутекс при ошибке, то мутекс будет poisoned, его нельзя восстановить без потери memory safety. То есть, ошибка в одном воркере может развалить весь сервер. Таким образом тебе нужно либо выполнять много расходных воркеров с координатором перезапуска, либо придумывать неординарные штуки, вроде тех, что сделаны в Rayon, который создаёт новое API с panic-safe функциями — естественно, подразумевается, что кроме этого API ты ничего не используешь, потому что иначе, опять-таки, паника, отравление данных, отказ сервера целиком.

Просто посмотри области применения Rust в 2026 — это по прежнему маленькие изолированные утилитки, отдельные микросервисы, serverless WASM фиговины (однопоточные), какая-то ограниченная однонаправленная обработка данных, и так далее. Нельзя написать на Rust большой законченный проект. Вот нельзя и всё, я запретил. Как ни странно, в этом плане Rust ближе к Haskell, чем к C++ — именно Haskell до сих пор прославилася тем, что для него никто не мог написать большого законченного интерактивного приложения.

byko3y ★★★★★
()
Ответ на: комментарий от byko3y

А нахрена не нем писать большие законченныеы проекты? Как и на си, впрочем. Я сам по началу пытался на нем полностью проекты писать, потом дошло, что я страдаю херней и я стал писать на нем модули к нормальным «быстрым» языкам - там где нужна производительность или где без низкоуровневого не обойтись.

LightDiver ★★★★★
()
Ответ на: комментарий от apt_install_lrzsz
[2026-04-24 22:03:24.701] Остановлен сервер на порту :32009
==2805== 
==2805== HEAP SUMMARY:
==2805==     in use at exit: 0 bytes in 0 blocks
==2805==   total heap usage: 250,586 allocs, 250,586 frees, 40,210,847 bytes allocated
==2805== 
==2805== All heap blocks were freed -- no leaks are possible
==2805== 
==2805== For counts of detected and suppressed errors, rerun with: -v
==2805== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Ой, как же так, на 16к строк ни одной проблемы с памятью. Наверное космические лучи изменили битики в valgrind и он всё врёт, ведь количество аллокаций не может совпадать на нагруженном драйвере устройства.

PPP328 ★★★★★
()
Последнее исправление: PPP328 (всего исправлений: 1)
Ответ на: комментарий от LightDiver

А нахрена не нем писать большие законченныеы проекты? Как и на си, впрочем.

ОС, СУБД, веб-браузер.

я стал писать на нем модули к нормальным «быстрым» языкам

Что такое «нормальные быстрые языки»?

byko3y ★★★★★
()
Ответ на: комментарий от cobold

Бизнесу надо показать кастомерам и правительствам в том числе, прогресс по усилению безопасности, так как это сейчас одна из точек продаж

Как ни странно, ценность раста для той же мозиллы была совсем не в этом. Как демонстрирует исходное сообщение, Rust безопасности не гарантирует, memory safety никакого отношения к уязвимостям логики не имеет.

Смысл Rust заключался в том, чтобы заменить опытного сеньора-крестовика на компилятор, таким образом сэкономив затраты на несколько этапов ревью. Если в C++ были скрытые небезопасные копирования, то в Rust это теперь явные unsafe.

Как ни странно, даже memory safety на практике Rust не гарантирует, потому что почти всегда используется тот или иной unsafe код, будь то растовый unsafe или внешние либы на C/C++.

byko3y ★★★★★
()

это разрывная… ничего против раст не имею, но это прям комок с гавном в их весь гламурно-безопасный пиар

SpaceRaven
()
Ответ на: комментарий от unC0Rr

Чтобы можно было добавлять новые фичи, не боясь поломать код и не тратя человеко-годы на каждую мелочь.

Ну вот за такое смузихлёбство раст и хейтят. За идиотское приравнивание memory safety к невозможности поломать код. За fearless нейрослопинг.

Manhunt ★★★★★
()
Ответ на: комментарий от DrRulez

Это - понятно. Пример просто кривоват как по мне. Это пример показал не какую-то кривизну языка Си, как такового, а результат оптимизации gcc, примененный к коду, к которому данный вариант оптимизации применять нельзя.

Ты немножко не понимаешь, как работает Си-шка. Не знаю, хочешь ли ты подразобраться в ней, но на случай если хочешь, оставлю вот эти ссылки:
https://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
https://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
https://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)
Ответ на: комментарий от byko3y

именно Haskell до сих пор прославилася тем, что для него никто не мог написать большого законченного интерактивного приложения.

leksah ?

monk ★★★★★
()

Это же надо так феерично обосраться. Раст в ядро? бггггг да они даже cp написать не могут, задача для школьника, начавшего изучать С.

int source = open("from", O_RDONLY, 0);
int dest = open("to", O_WRONLY | O_CREAT, 0644);
struct stat stat_source;
fstat(source, &stat_source);
sendfile(dest, source, 0, stat_source.st_size);
close(source);
close(dest);
Lusine
()

Анекдот дня. Программиста на cpp заменили тремя молодыми на раст.

Lusine
()
Ответ на: комментарий от monk

именно Haskell до сих пор прославилася тем, что для него никто не мог написать большого законченного интерактивного приложения.
leksah ?

Это IDE для Haskell, это не IDE, написанное на Haskell. У Haskell там роль примерно как у баша в убунте:

--------------------------------------------------------------------------------
Language                      files          blank        comment           code
--------------------------------------------------------------------------------
SVG                             218            275            213         147939
JavaScript                      300           7655           5899          67503
Haskell                         121           3060           2355          28302
HTML                            182           3840             11          23029
CSS                              78            950            626           5807
XML                              21            406            435           3076
Markdown                         10            809              0           1486
reStructuredText                 12            564             95           1360
PO File                           1            557            561           1140
Bourne Shell                     22            150             93            747
byko3y ★★★★★
()
Ответ на: комментарий от LightDiver

Модули к проектам на ts, например.

И что нормально-быстрого в TypeScript? Ты же не хочешь сказать, что пишешь базы данных на языке для HTML кнопочек?

byko3y ★★★★★
()
Ответ на: комментарий от Lusine

Знаешь, в чем проблема? Клоун должен быть смешным. А ты - не смешной, ты унылый.

Manhunt ★★★★★
()

Как-Мне-Кажется, не ошибается лишь тот, кто ничего не делает; и первый блин комом, соответственно.

Мне думается, что раст-коре-утилс свой юзкейс найдут. Просто пока-что их надо фуззить и дебажить (+ревьюить нейрослопкой).

В чём смысл новости, я так и не понял… Что «с первого раза пионэры нешмагли»?

Да и вообще докучи — в резерве находятся гну-коре-утилс, основанные Столлманом. Если что-то временно не работает — просто переключаем пару программулин на резерв, и усё.

Set440 ★★
()
Ответ на: комментарий от Set440

В чём смысл новости, я так и не понял…

поджечь пуканы любителям раста

Lusine
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.