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

А потом еще херакс и ВиндовсСервер начал теснить линукс на серверах.

Он никогда не теснил линукс. Windows Server возник как совершенно отдельное направление и вытеснил Novell, OS/2, Banyan VINES и другую корпоративщину.

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

Надо опрос запилить, и окажется что 85% живут в многоэтажных домах в городе

Они строят, потому что я хочу жить в таких домах и покупать в таких себе хатку, поближе к работам, сервисам, с поликлиникой чтобы и скорой

С какой стати, мне интересно знать, кто то должен бросить строительство таких домов как сейчас

Мне например наоборот очень не нравится как у пиндосов с их бесконечной дорогой до работы и до центра города. Хотя многие в городах имеют дачу с домом 100-150 кв. м.

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

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

Ради интереса: за какое время у тебя соберётся WezTerm?

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

Это самый здоровый коммент в треде к этой странице. Думаю, и во всём треде.

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

Надо опрос запилить, и окажется что 85% живут в многоэтажных домах в городе

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

Они строят, потому что я хочу жить в таких домах

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

С какой стати, мне интересно знать, кто то должен бросить строительство таких домов как сейчас

Ни с какой: никто, кроме тебя, этого и не писал...

Мне например наоборот очень не нравится

Это твоя личная проблема. Другим может не нравиться (и не наверняка не нравится) то, что «нравится» тебе... Так уж устроена жизнь: все люди разные... :)

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

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

Я думаю

Судя по комментам получается, пока что, так себе :)

Посмотри что-ли новости по тегу - Rust уже в ядре, причём не в экспериментальном статусе. Хотя, конечно, какому-то анонимному балаболу с форума куда виднее что там и как будет с технологиями чем разрабам ядра. Они что - так, пыль: код там какой-то пишут несколько десятилетий. То-ли дело анонимный хрен - он-то Думал! Хорошо хоть не уточнил чем именно - судя по результату это не общепринятый орган.

zabbal ★★★★☆
()
Ответ на: комментарий от dataman
    Finished `release` profile [optimized] target(s) in 13m 57s
cargo build --release  3694.77s user 189.38s system 463% cpu 13:57.38 total
diver ~/sources/test/wezterm-main %      

Для такого болшого проекта это практически мгновенно. 99% времени собирались модули, в конце пости сразу сам проект.

Учти, что у меня принудительно проц урезан до 800мГц.

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

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

Хотя, вебкит то я собирал не у себя на машине. Сначала несколько попыток на гитхабе по 2,5 часа. Потом у согильдийца на винде несколько неудачных попыток по несколько часов.

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

Я собираю около десятка консольных утилит на Расте, и мне вот интересно, есть ли возможность обновления крейта во всех остальных, зависящих от него?
А то часто бывает, что cargo скачивает несколько версий одного и того же крейта.

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

Эм.. Так сделай корневой Cargo.toml, в нем укажи зависимости.

Наверное что то вроде: my-common-lib = { path = «../my-common-lib» }

И в либах в свою очередь: my-common-lib = { workspace = true }

workspace + workspace.dependencies

потом:

cargo install cargo-upgrades
cargo upgrades

Я разок делал такое, вроде работало. Правда потом запутался в сборках линукс+винда и вообще все разнес по отдельным папкам. Так проще ориентироваться в итоге, когда все в своем отдельном проекте.

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

Так сделай корневой Cargo.toml, в нем укажи зависимости.

Так он уже есть, я же хочу чужие проекты так обновить.

потом:

cargo install cargo-upgrades

В какой-то версии cargo добавили же команду upgrade «в коробку».
А может и путаю. :)

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

Я до сих пор на edition = «2021» сижу. Надо глянуть чего там сделали. Я редко в раст заглядываю, в основном - луа, js, ts.

Вообще стараюсь в особо новое и последнее не лезть. Мало того что вечные баги, так еще и их фичи новые хрен все учтешь.

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

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

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

И всё же, многоэтажки 20-30 мне нравятся очень очень. Они символ развития прогресса, знак силы экономики. Экономия места, хотя для РФ это вообще не актуально, пусть лучше лес растет чем нелепые дачные дома (иногда бывают не уродливые). Что то в этом есть, люблю больше чем дачные дома

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

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

Зачем тебе нужна свободная, полностью подчиняющаяся жёстким стандартам? Чтобы что? Денег не платить? На Винду не заработал?

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

Так я говорю - винда, а лучше красные папочки. Где-то оно что-то крутится, а как оно там - доложат

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

Хорошо, я ведь не ради спора…

Я тоже просто высказываю здесь своё мнение по вопросам, которые мне так или иначе близки, небезразличны...

И всё же, многоэтажки 20-30 мне нравятся очень очень

А мне не нравятся совершенно. И у меня есть «железобетонные» доводы «против». Но здесь этому явно не место, так что и не буду... :)

Они символ развития прогресса, знак силы экономики

Нет. :)

думают как ты

Нет. :) Все думают, как они сами... :))

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

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

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

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

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

переносят работу с компилятора на программиста

А что это за «работа» такая, которую можно «перенести с компилятора на программиста»?? Ж8-О ;))

Неужели у вас компиляторы, которые умеют мыслить, но заставляют думать головой (верхней, имеется в виду ;P ;) ) «погромистов»??.. ;)))

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

См. ОП.

Язык что обещал, выполнил. Для этой мутной посикс-утилитной помойки это-то чудо что так мало ошибок(и только логических) за такой срок реализации.

Быстрее C/C++?

Давно уже, особенно, на коде который должен быть одновременно и быстрым и корректным и хорошо читаемым.

«Ни ООП, ни исключений.»

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

Заморочились одной единственной фичёй, всё остальное ниасилили.

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

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

А что это за «работа» такая, которую можно «перенести с компилятора на программиста»??

  1. выведение типов - теперь модно снять с компилятора и положить на программиста
  2. трансляцию ошибок вверх по стеку
  3. и вот в rust ещё и управление памятью на программиста навесили
rsync ★★
()
Ответ на: комментарий от rsync

выведение типов

А эт-то что за зверь?? Может, таки «вывод»?.. ;)

теперь модно снять с компилятора и положить на программиста

Ну и что? Этому-то «кудеснику"должно быть лучше известно, что он там „нафеячил“... Вот пусть он и...

трансляцию ошибок вверх по стеку

Без комментария... :)

и вот в rust ещё и управление памятью на программиста навесили

Видимо, это и есть та самая „безопасность“, „о которой так долго говорили большевики“... ;P ;)))

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

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

Во, ты отлично описал ключевую мотивацию перехода с С на Rust.

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

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

Но самое главное, что нормализация открытости ОС и доступности пересборки поставила бы крест на желании проприетарщиков и диктатур сделать всё на свете подписанным и защищенным, без возможности поставить «нежелательную» ОС. Гуглить проблемы age verification и иже с ними.

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

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

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

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

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

Ну и что?

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

и человек вместо того, чтобы тратить время на что-то конструктивное, верхнеуровневое - теперь имается с if (error) return error (да я знаю, что в Rust осознали косячность парадигмы отказа от исключений и приделали вопросик, но вопросик близко не стоял по удобству с try-catch блоками)

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

Проблем с владением не существует, если ты пишешь код корректно, то оно само по себе работает. Борьба с боровом возникает только на начальном этапе, и это быстро проходит.

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

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

заставить их в каждой строке кода помнить о владении

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

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

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

macos - передает привет :) вместе с playstation, до кучи. ну и как вишенка на торте ms azure

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

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

Может я конечно и не прав, но всегда считал UB платформо-специфичной вещью. Иначе говоря, если бы поведение было бы разное при комлиции в x86 и, условно, в ARM, то это норм. А так, чтобы поменять ключить в рамках одной платформы, то это перебор.

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

Иначе говоря, если бы поведение было бы разное при комлиции в x86 и, условно, в ARM, то это норм.

Есть implementation-defined behavior — когда результат предсказуем, но может зависеть от компилятора, целевой архитектуры и т.д.

А так, чтобы поменять ключить в рамках одной платформы, то это перебор.

А UB — это когда один и тот же код, оказавшись в разном контексте (например, есть функция f1, которая вызывает f2, и компилятор решил f2 заинлайнить — всё, контекст для кода в f1 изменился), может компилироваться по-разному. Даже когда ключи компилятора одинаковые — например, эвристика упомянутых инлайнов зависит от размера функций, одну строчку в коде поменял и всё.

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

Проблем с владением не существует, если ты пишешь код корректно, то оно само по себе работает. Борьба с боровом возникает только на начальном этапе, и это быстро проходит.

Перевожу на русский язык: «Человек - не таракан, ко всему привыкнет. Можно привыкнуть и к Rust»

Только открытый вопрос: зачем это делать?

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

компилятор заботливо проследит за этим

Есть большая разница между:

  • компилятор заботливо следит за этим (сам)
  • компилятор следит, чтобы пользователь следил за этим (сам)

Если первое - это про удобство, то второе - про садизм в отношении программиста.

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

компилятор заботливо следит за этим (сам)

компилятор следит, чтобы пользователь следил за этим (сам)

Эээээ… Непонятно где подразумевается компилятор раста, и где компилятор плюсов.

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

Эээээ… Непонятно где подразумевается компилятор раста, и где компилятор плюсов.

плюсы Вы сами себе здесь придумали.

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

а Rust - садистски это делает

а «следит сам» - например, компилятор golang. или лучше - компилятор Perl.

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

Проблем с владением не существует, если ты пишешь код корректно, то оно само по себе работает. Борьба с боровом возникает только на начальном этапе, и это быстро проходит.

Перевожу на русский язык: «Человек - не таракан, ко всему привыкнет. Можно привыкнуть и к Rust»
Только открытый вопрос: зачем это делать?

Это, как раз, очень простой вопрос: job safety. Если ты умеешь ездить на одноколёсном велосипеде, то это твоё преимущество, потому что другие люди на одноколёсном велосипеде ездить не умеют. Чем неудобнее инструмент, тем больше преимущество того, кто этим инструментом мастерски владеет.

А ты думаешь, почему кобол так долго не могли вывести, даже с дихлофосом?

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

UB это состояние которое не должно возникать в совместимой программе.

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

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

Но так как обращение к нулевому указателю это UB, значит компилятор считает, что указатель точно не нулевой. И выкидывает весь код, связанный с проверкой.

Этим UB отличается от Unspecified и Implementation-defined поведения, которые подразумевают, что «какое-то» состояние у программы таки есть.

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