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)
Ответ на: комментарий от byko3y

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

Так ты документацию с кодом посчитал. Зайди в src.

~/tmp/leksah/src$ cloc .
      67 text files.
      67 unique files.
       0 files ignored.

github.com/AlDanial/cloc v 2.08  T=0.11 s (630.9 files/s, 158889.8 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Haskell                         67           1536           1300          14037
-------------------------------------------------------------------------------
SUM:                            67           1536           1300          14037
-------------------------------------------------------------------------------

P.S. По твоей статистике leksah является изображением в SVG?

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

Точнее, там три каталога с исходниками:

~/tmp/leksah$ cloc src*
     107 text files.
     107 unique files.
       0 files ignored.

github.com/AlDanial/cloc v 2.08  T=0.19 s (560.3 files/s, 174183.8 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Haskell                        107           2998           2253          28012
-------------------------------------------------------------------------------
SUM:                           107           2998           2253          28012
-------------------------------------------------------------------------------

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

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

Прям юниксвей, второе пришествие.

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

Чтобы сишку закопать. Лидеры рынка тупо скинулись на убийцу сишки

Белка-истеричка.jpg

На наш век хватит. Каждые несколько лет всё скидываются на очередных убийц C/C++, а они всё никак не собираются помирать.

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

Где ты видишь истерику, дятел-аналитик? Мне идеально сферически плевать на судьбу сишки.

Каждые несколько лет всё скидываются на очередных убийц C/C++, а они всё никак не собираются помирать.

Пока вижу, что ржавчина продвигается намного успешнее других.

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

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)

б-же храни Canonical, что тратят $$$ на развитие опенсурца

Ошибка в коде разбора аргументов утилиты kill позволяет отправить сигнал всем процессам в системе при указании идентификатора процесса -1 (kill -1).

хаха

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

От «думать не надо, компилятор всё порешает» мы уже давно перешли к «думать совсем не надо, ии всё порешает». Весёлые времена грядут.

beastie ★★★★★
()

Черт, опоздал к началу срача. Ну ладно, продолжайте без меня %)

Справедливости ради, эти уязвимости не относятся к управлению памятью. От логических ошибок раст не защищает.

liksys ★★★★
()

Очередной факт что финскую поделку на горбах студентов шизиков не довести до уровнях хотя бы bsd никогда и ни с каким языком.

ponchik-2
()
Ответ на: комментарий от vbr

Смешная шутка.

Подмена понятий. Это проблема не языка как такового, а его реализации в конкретном компиляторе.

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

Я так и не понял что они хотели изобразить этим переписыванием. Что бы что?

Я вот думаю что главная причина это «MIT License». Всё остальное надуманное.

У тех, кто стоит за внедрением этого, есть такие головы на плечах, чтобы одновременно преследовать несколько целей.

Осмелюсь предположить, что Rust – это язык, оптимизированный для программирования с использованием нейросетей в качестве помощников. Только для того, чтобы они стали полезны в таком качестве, нужен годный материал для их обучения. Те, кто занимается переписыванием на Rust и так нормально работающего софта, готовят такой материал. Ну а то, что в процессе переписывания возникают ошибки, тут, как говорится, лес рубят – щепки летят.

Попутно могут решаться, например, еще и такие задачи:

  • у проекта на Rust – свой новый формальный/неформальный лидер, чей нужно ставленник, который направляет его развитие в нужное русло;
  • для того, чтобы эффективно писать на Rust, понадобится доступ к обученным нейросетям, которые будут находится во владении у правильных людей и доступ к которым будет предоставляться на их условиях. На открытых исходниках обучать нейросети теоретически может каждый, но нормально работающий агент – помощник – это не только нейросеть, но еще и куча всяких обвязок (venturebeat.com: Karpathy’s March of Nines shows why 90% AI reliability isn’t even close to enough), да и необходимое для обучения железо далеко не всем доступно.
Zaruba
()
Ответ на: комментарий от Zaruba

Столько ненужного пафоса, чтобы переписать банальнейший cp с ошибками? Куда то не туда они пошли.

Lusine
()

Вопрос. Если перепишут Нейролинукс(тм) на расте, лучше оригинала, чья это будет собственность?

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

Вовсе нет. UB - это часть стандарта Си. А по ссылке было развернутое, с примерами, объяснение того, что такое UB. Если ты пишешь без учета UB, то ты пишешь не на Си, а на каком-то своём, воображаемом Си-подобном языке. А компилировать код пытаешься компилятором для Си. Естественно, что получается фигня. Оптимизатор тут вообще не при чем.

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

возвращены утилиты cp, mv и rm из набора GNU Coreutils

Но как же... Но как же СВИТАЯ БИЗАПАСНОСТЬ?

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

Да, в так называемом «стандарте Си» описаны артефакты оптимизатора.

не на Си, а на каком-то своём, воображаемом Си-подобном языке

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

А компилировать код пытаешься компилятором для Си. Естественно, что получается фигня. Оптимизатор тут вообще не при чем.

Я компилирую код компилятором Си и получается всё хорошо. Потому что я учитываю поведение используемого компилятора Си при написании кода. Комитетская графомания про UB тут имеет только косвенное отношение. В частности, если не указывать опасные опции типа -O3, или если даже её указать, но сопроводив исправляющей опцией -fno-strict-overflow то забагованность знаковой арифметики не проявляется. Всё это указано в мануале к gcc.

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

Сам посмотри, как твой gcc обращается с UB при «безопасном» O2: https://diekmann.uk/blog/2024-06-25-statically-known-undefined-behaviour.html

Авторы компиляторов по факту смотрят именно в стандарт, никакой больше твёрдой опоры для трактовки кода на Си не существует

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 2)

«Руст - это глобально и надёжно», — говорили они.

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

Ubuntu намного чаще используется в индустрии, чем Arch, это тупо факт. И сервера на Ubuntu работают.

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

Выбор сырого проекта был ошибкой. Убунта непонятно зачем решила попиариться.

Убунта в переводе с раста на человеческий означает мокрое место. Для них выбор логичен.

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

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

Уже миллион раз повторяли, что Homo Sapiens принципиально не способен писать на Си без ошибок, так наш несовершенный мозг устроен, что человек обречён совершать определённое количество ошибок на единицу кода в среднем. И ошибки программирования на Си приводят к катастрофическим последствиям в виде компрометации всего адресного пространства, где работает код на Си.

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

если даже для просмотра своего старого кода проще скормить его ИИшке

… То ты либо написал его, будучи под градусом в состоянии летающих аквалангистов, либо уже стал профнепригоден.

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

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

Очень ты странный: для меня всегда очевидно что делает мой старый код. Хоть бы по названиям сущностей, да я и без этого всегда помню, даже смотреть не надо

pihter ★★★★★
()

В Ubuntu 26.04 возвращены cp, mv и rm из GNU Coreutils

Может, дойдём до того, что sysv init вернут?

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

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

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

Убунта в переводе с раста на человеческий означает мокрое место. Для них выбор логичен.

С этим не спорю.

Раст - не золотая пуля. Он защищает только от ошибок памяти, и не более того. От выключенного мозга во время написания кода не защищает вообще ничего.

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

А винда чаще на десктопах стоит, чем Линукс.

Это аргумент качества сборки что ли?

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

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

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

Если мне не изменяет склероз, Rust придумал и довел до ума OCaml-ист, причем делал он это на OCaml-е.

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

O2 не безопасный, к нему тоже надо -fno-strict-overflow писать. Я не писал что опасный только O3, там написано «типа O3». O1 тоже опасный местами, так что если хоть что-то кроме -O0 стоит - надо писать -fno-strict-overflow. А ещё -fno-strict-aliasing - это ещё одна оптимизаторная чушь которую надо сразу выключать.

никакой больше твёрдой опоры для трактовки кода на Си не существует

Опора - спецификация (или исходники) компилятора. Графомания комитетов - побочный документ, который иногда как-то влияет на желания авторов компиляторов.

И сразу уточню, на всякий случай. Я в курсе, что кроме указанных двух проблемных оптимизаций имеются и другие, но разговор был про signed-баги, я про них и писал. Если надо точно отключить всю гадость - ставь -O0, в остальных случаях надо быть осторожным на предмет подстав.

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

Rust позволяет избежать целого класса ошибок, приводящих к катастрофическим последствиям. Так что программистами равной квалификации программа на Rust будет написана с меньшим количеством критических ошибок, чем на на Си. Все ваши лулзы берутся от программистов, не умеющих писать ни на Rust, ни на Си. Это некорректное сравнение.

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

Раст - не золотая пуля. Он защищает только от ошибок памяти, и не более того. От выключенного мозга во время написания кода не защищает вообще ничего.

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

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

А винда чаще на десктопах стоит, чем Линукс.

У вас есть сомнение, что на то есть объективные причины?

Это аргумент качества сборки что ли?

Не знаю что это за «качество сборки» такое, если бизнесу от него нет никакого толку. Сервера на Arch не начинают работать принципиально лучше и экономить деньги владельцам.

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

Rust не должен ни с чем бороться, это просто инструмент. И не надо удивляться, что всё выходит через жопу у тех, кто не умеет пользоваться этим инструментом.

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

Rust - Ты же должен был бородся с уязвивомастими, не быть как все

Раст победил все уязвимости и теперь по праву занимает их место.

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

Арч не предназначен для установки на сервера, потому что нет гарантий по времени жизни пакетов.

Давайте еще на полном серьёзе обсудим, стоит ли вилкой есть суп.

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

Сравнение корректное, но ты несколько не понял что именно сравнивается.

«Равной квалификации» это дополнительное условие, которого не было. Один из тезисов как раз в том, что раст-кодеры систематически оказываются более низкой квалификации, чем Си. И это ставится в вину расту: Си отфильтровывает идиотов, их поделки сегфолтятся при запуске, идиоты расстраиваются и уходят. Раст не отфильтровывает, а помогает сделать вид, будто идиот сделал что-то работающее. Идиот радуется и продолжает свою вредоносную деятельность.

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

Если ты пишешь без учета UB, то ты пишешь не на Си, а на каком-то своём, воображаемом Си-подобном языке. А компилировать код пытаешься компилятором для Си. Естественно, что получается фигня.

Ерунду какую-то написал. Если компилятор соответствует стандарту и скомпилировал код, значит код написан на C. UB говорит лишь о том что стандарт не требует какого-то конкретного поведения.

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

Rust позволяет избежать целого класса ошибок

Не избежать, а минимизировать. Ценой переусложнения разработки.

Так что программистами равной квалификации программа на Rust будет написана с меньшим количеством критических ошибок, чем на на Си.

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

Это некорректное сравнение.

Вам бы так хотелось, но нет. Как вы правильно заметили ошибки допускают люди, сравнение корректное.

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

Экосистемно Раст это новый JS. При чём в варианте экосистемы node js.

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

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

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

Пишешь вроде про раст, а выходит про ИИ.

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