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

Это значит твой код на уровне детсада.

Просто, давай уточним.

Если я по памяти ориентируюсь в своём коде и всегда помню(понимаю) что там и зачем, то это значит что мой код на уровне детсада?

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

Я когда начинал, с ужасом думал о проектах на 10 тысяч строк кода, не говоря уже о сотне или миллионе. А потом как то строчка за строчкой, функция за функцией оно каак разрослось. И без ООП я пришел в тупик уже на 45 тысячах строк кода.

Просто уже физически стало невозможно поддерживать проект. Поддержка любой фичи начала занимать до бесконечности времени - просто для отслеживания всех логических цепочек. А еще они все багались. Десятки, сотни непроверенных крайних случаев. Там нет проверки на тип, там у тебя таблица запрашиватеся, а ее не существует еще у юзера!

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

А потом пришли ИИшки и это было сравнимо с двумя концепциями ООП разом.

И тут вдруг мне говорят - а чо такова? Ты просто делай правильно и запомни все свои концепции. Юмористы, блин. Такое ощущение, что все вокруг какие то сверхлюди, все могут, все им просто и понятно. Один я дурак.

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

А программисты в целом народе очень специфичный. Я когда начал все это изучать плотно, мне люто повезло нарваться на одного адекватного в ирке, который мне все разжевывал при необходимости. Терпеливо, без нервов по запросу. И парочку средней адекватности тут на форуме. Тот же LINUX.ORG.RU дал мне концепций на годы, которыми я пользовался раз за разом.

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

Ну ты можешь посмотреть общение тут на форуме между профессионалами. Это какая то общая особенность мышления чтоли. Возможно другие в этой профессии не выживают.

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

эта проблема (0 оконеченных) - легко решаемая при желании, ИЧСХ, даже механизмы в С уже давно завезли, чуть ли не с самого начала.

но причину почему было сделано именно так - я вам легко объясню.

это связано с простотой и быстротой обработки основных действий со строками (не всех). что хорошо подходило под те реалии.

ведь ведение строк фиксированной длины требуют где-то отдельно и постоянно хранить их длину и мало того, ещё как-то её передавать.

все варианты имеют свои плюсы и минусы.

а 0 конечные строки передавать - очень просто - дал указатель и вася кот! в тогдашней архитектуре процессоров - очень просто и эффективно. а фиксу - начинаются пляски. и да - очень скоро всё пришло бы к другой проблеме - varchar(255) в SQL ни на какие мысли не наводит?

и это всё так сложилось, а потом уже люди стали лениться что-то менять. хотя никто не запрещал strncpy пользоваться.

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

Так очевидно - кучи готовых модулей, кучи готовых анимаций. Любая реализация чего угодно уже готова (почти). Ты можешь брать кирпичики и строить из них дом а не создавать каждый кирпичик вручную.

Если тебе надо кроссплатформенность - вот она в два клика. Тебе нужен список модулей - вот он в одну команду. нужно подтащить разные модули - записал их в файл, прописал команду - все, они у тебя.

Тебе не нужно ждать сборки минутами и часами. Даже с ts сборка это пара секунд и все, у тебя готовый проект.

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

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

LINUX.ORG.RU дал мне концепций

Классы на 10 тыс. строк? Даже боюсь спрашивать, чему еще тебя тут научили. А что помешало просто прочесть книжку типа «Паттерны разработки и рефакторинга»?

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

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

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

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

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

Это значит, что за деревьями ты леса не видишь. Ориентироваться надо в предметной области, а не в буковках на С. Код маленький вот и ориентирушься. А серьезные задачи с маленькой кодбазой не решить.

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

Это я не про проект (не про сайт), а про юзера с такими ником. Он мне дал основы, базу невероятно удобную.

https://github.com/Vladgobelen/Coffee/blob/main/coffee.lua

Вот с этого его скрипта я начал путь в программирование. Тогда мне это казалось невероятно сложным. Система флагов, циклы - гениально же. У меня до сих пор многое на таких приципах работает.

LightDiver ★★★★★
()

Вообще, есть смысл изучать Rust? Или это очередная новомодная мертворожденная технология? Перспективы есть?

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

Почему сильнее? По-моему это одно и то же, только разные люди традиционно к разным вариантам привыкли.

no-common это не оптимизация а скорее слежка за качеством кода, но некоторые проекты от него ломаются т.к. авторы забывают extern прописывать.

Касательно O0 - если скорость упирается в диск/сеть/сисколлы то эта разница будет всё ещё несущественна, зато меньше опасений. Для числодробилок да, имеет смысл ставить хотя бы -O1.

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

Ему хотя бы можно своими словами объяснить что ты хочешь найти и он тут же покажет тебе это. Мгновенно. И он своими словами хоть как то тебе опишет проект. От этого уже можно отталкиваться. Даже со всеми их минусами - это очень много.

Да, они не видят иногда очевидного, но и пользы выше крыши.

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

Да, разные книжечки убили мне 20 лет жизни, так ничего и не дав на практике. И сишка, куда же без нее. Угробила мне все, что только можно. Не понимаю почему я раз за разом пытался на нее залезть.

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

Это у тебя есть работа с базами в библиотеках. А есть такие проекты, где нихрена готового нету. А если есть - не на твои версии. А если на твои версии, написанное в 2008 году без документации.

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

Нет. Большинство пишут на С/С++ десятилетиями, и им похрену на раст, ничего полезного он не привносит, что тратить на это время.

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

Раст прекрасен. Это ванлав. Ты попробуй его. Может это у меня такой эффект индивидуален, но мне он зашел с первой строчки кода в каждой его детали.

А про перспективы - общемировой хайп по нему возник не просто так.

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

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

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

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

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

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

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

Спасибо, OpenOffice уже написали на плюсах. Написали так, что поколения людей думали он на яве.

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

Но ты же понимаешь, что эти якобы «хипстеры» - крупнейшие корпорации мира? Именно гугл, майкрософт и подобные пропихивают сейчас раст активно.

https://www.opennet.ru/opennews/art.shtml?num=64251

Вот я загуглил первое попавшееся просто для примера.

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

Очередная демонстрация того факта, чтоОчередная демонстрация того факта, что

человечество стремительно деградирует, и если для своего времени (UPD: и своих задач) C был офигенен, то нынешние смузихлёбы не способны ни качественный современный язык написать, ни какой-либо другой качественный софт – ни на своём языке, ни на каком-либо другом.

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

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

«Весь год внедряли Rust, руководство хочет получить свои премии и бонусы ведь близится конец года. Что делаем? Шлёпаем красивые отчётики с доказательством собственной экономической эффективности и премия в кармане.»

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

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

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

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

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

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

Я и сам на плюсах пишу. Мерзость та ещё, но для системного, десктопного, да и просто любого сложного и быстрого софта – альтернатив пока не вижу. Но я не о том говорил.

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

У микрософта офис на плюсах. И?

В 1995 году был Си с классами и архитектурные астронавты только-только поднимали голову.

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

А что в других премии и бонусы не хотят? Была команда на уровне государства «писать на безопасных языках», все под козырек и понеслось. Очковтирательство это общепринятая мировая практика.

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

Перспективы… гы. Всё, он уже везде и активно растёт, отчего и всё это нытьё и истерики хейтерочков. Расклад сейчас такой(это на собственном опыте в том числе) - нужно что-то околосистемное, в смысле, надёжное, быстрое, технологичное - однозначно раст. Отдельный плюс растовая многопоточка - лучше нет нигде, асинк замороченный но тоже стоит того. А вот если надо просрать и сроки и качество ради сомнительной ценности хакирной короны, то тут сишечка вне конкуренции. Плюсцы тоже активно коболизируются и дипрекейтятся.

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

Серьезный объем кодовой базы это сколько сотен тысяч строк? Или уже миллионы? А если структурирован, или реализует стандарт, который «понятен сверху»?

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

акробат, вполне себе качественный софт

Учитывая какой говнокод ты в тред закинул - неудивительно что для тебя и дырявое убожество акробат качественным кажется.

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

Даже не знаю, что сказать. Наверное «молодец, возьми с полки пирожок» прозвучит грубо. А зачем ты заменил int на unsigned int? Чтобы что? Весь смысл моего примера был в том, чтобы наглядно показать, что целочисленное переполнение в C это undefined behavior и последствия этого самого UB. И в более общем смысле чтобы продемонстрировать абсурдность фразы «делает то, что хочет программист» применительно к С.

Но раз уж ты взялся - давай, реализовывай сложение двух целочисленных чисел, с возможностью переполнения и без UB/IDB.

кстати, без return gcc ошибку у меня давал и не собирал код

Не может быть.

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

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

Вот когда подобные мысли накатывают или синдром самозванца накрывает - непременно иду на ЛОР, читаю комментарии местных хейтеров и всё сразу проходит.

Эти, гордо несущие свою цефалоремиссию в мир, точно не угроза сытой старости :-D

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

Значит дело не в языке, а в квалификации разработчиков.

Об этом и речь.

Quake 3 Arena 1999 практически целиком на Си.

Unreal 1998 практически целиком на С++.

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

Уже 10 лет слышу ко-ко-ко про смерть сишечки, а она жива и всех нас переживет.

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

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

тем более тут всё ясно и понятно написано (я про gcc):
Despite this requirement of the standard, many C programs and Autoconf tests assume that signed integer overflow silently wraps around modulo a power of two, using two’s complement arithmetic, so long as you cast the resulting value to a signed integer type or store it into a signed integer variable. If you use conservative optimization flags, such programs are generally portable to the vast majority of modern platforms, with a few exceptions discussed later.

use conservative optimization flags, Luke!

-O0

и это ты взялся реализовать странное. я лично не подписывался на это.;-)

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

впрочем, после четырёх printf вместо одного (между прочим, он хорошо так весит по времени и CPU) - трудно ожидать разумного.))))

mumpster ★★★★★
()

В программах бывают ошибки! Шок! Сенсация!

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

А что, тогда были альтернативы?

Конечно были. И Дельфи, и Вижуал Пролог.

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

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

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

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