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

Чтобы стать, надо сначала быть кем-то другим.

Был профпригодным, но не пригодился. А теперь все хорошо.

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

Значит однозначно. Название сущностей он помнит, ага. Когда у тебя не детский сад, в проекте > 400 Maven модулей и 1,000 configuration properties.

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

Ты немножко не понимаешь, как работает Си-шка.

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

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

Я до такой степене просветления не добрался. У меня проекты некоторые уже по 85+ тысяч строк, разрабатываемые последние три года на разрых этапах понимания программирования. И чтобы многое вспомнить и понять, надо долго вчитываться в код ходить по файлам, восстанавливать цепочки событий.

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

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

А вчитываться в чужой код - это на несколько порядков дольше. Там ИИшки вообще бесценны.

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

Ну то есть твой студент не только man sendfile не читал, но и man cp

The in_fd argument must correspond to a file which supports mmap(2)-like operations (i.e., it cannot be a socket). Except since Linux 5.12 and if out_fd is a pipe, in which case sendfile() desugars to a splice(2) and its restrictions apply.

sendfile() will transfer at most 0x7ffff000 (2,147,479,552) bytes, returning the number of bytes actually transferred. (This is true on both 32-bit and 64-bit systems.)

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

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

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

Авторы компиляторов по факту смотрят именно в стандарт

В какой из? А то их, знаешь, чуть больше чем дохрена.

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

DrRulez ★★★★★
()
Ответ на: комментарий от cobold
import os
import socket
import time

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.bind(('127.0.0.1', 8080))
sock.listen(1)

try:
  print("Waiting for connection on port 8080...")
  conn, addr = sock.accept()
  print(f"Connection from {addr[0]} : {addr[1]}")
  start = time.time()
  file_size = os.stat('bigfile').st_size
  print(f"{file_size} bytes to send")
  with open('bigfile', 'rb') as f:
    zerocopy_result = None
    offset = 0
    while zerocopy_result != 0:
      zerocopy_result = os.sendfile(conn.fileno(), f.fileno(), offset, 4096)
      offset += zerocopy_result
  conn.close()
  end = time.time()
  print(f"Time to send file : {end - start}")
except KeyboardInterrupt as e:
  pass

sock.close()

все работает и с сокет тоже

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

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

Раст - претендует на звание системного языка программирования! Это подразумевает полный доступ к любому оборудованию. Си, как и ассемблер - данный функционал предоставляют. Раст делает это через костыли вроде unsafe. Да - это помогает обратить внимание на участки кода. Но абсолютно тоже самое в состоянии сделать банальный комментарий в коде на Си.

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

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

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

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

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

разрабатываемые последние три года на разрых этапах понимания программирования.

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

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

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

Вовсе не значит.

Ситуация такая:
1. Программист в своем манямирке что-воображал о своем коде;
2. Компилятор истолковал этот код совсем иначе: не так как мриилось горе-программисту, а так как написано в стандарте языка;
3. Программист запустил программу, удивился что она работает «не так», и стал лепетать что-то про «оптимизатор».

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

Это два разных Си: воображаемый Си-подобный язык из головы горе-программиста, и реальный Си из стандарта. Синтаксис похож, так что компилятор реального Си зачастую компилирует и то, что исторгают из себя программисты. А вот семантика у языков - существенно разная, но горе-программисты этого не осознают, и считают что виноват «оптимизатор» (в коде реального компилятора никакого «оптимизатора» нет, а есть различные проходы/фазы компиляции, обычно intermediate representation с static single assignment, с разрозненными опциональными преобразованиями на различных фазах).

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

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

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

У меня иногда такое ощущение, что ты просто бредишь. Три года назад я даже не понимал как использовать функции и цикл for с гуглом писал.

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

Не избежать, а минимизировать.

Ошибок порчи памяти вне unsafe блоков Раст позволяет избежать на 100%, а не просто минимизировать. Это математически доказывается.

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

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

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

Компилятор истолковал этот код совсем иначе: не так как мриилось горе-программисту, а так как написано в стандарте языка;

Если программист пользуется компилятором, не понимая что и как он компилирует - это плохой программист, да. Только вот твои фантазии про некие «настоящие» и «ненастоящие» Си тут ни при чём.

реальный Си из стандарта

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

Си из ISO - не реальный, референсного компилятора у него нет. Он теоретический. Теоретических Си тоже много, потому как спецификациеписателей много. Для общего развития знать их тоже, наверно, немного полезно, но менее полезно чем знать реальные (см. выше).

в коде реального компилятора никакого «оптимизатора» нет

Ты написал Си-компилятор без оптимизатора? Где можно с ним ознакомиться? В популярных компиляторах (gcc и даже шланг) оптимизаторы есть.

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

На установки на десктоп Линукс вообще не предназначен

Ты на утро не те трусы занюхнул?

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

Хочешь нормальную юникс-систему? Вон иди в магазин и покупай мак. Сейчас даже гипотетический московский бомж может это сделать, купив макбук нео.

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

Компилятор истолковал этот код совсем иначе: не так как мриилось горе-программисту, а так как написано в стандарте языка;

Повторю сакраментальный вопрос - какого именно стандарта?

Могу добавить еще один - на закуску. Какие именно современные компиляторы поддерживают самый свежий стандарт языка Си ?

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

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

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

Ошибок порчи памяти вне unsafe блоков Раст позволяет избежать на 100%

Это полное, 100% враньё: https://github.com/Speykious/cve-rs

Т.к. раст писали растаманы, то всё их safe такое же, как и всё остальное написанное растаманами.

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

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

абсолютно с тем же самым подходом пишут реализацию этого самого safe в самом расте.

Жёваный крот, я не понимаю как вообще можно в упор не видеть этого и наивно полагать что все эти заявления растаманов про «БизАпаСТнасть» написанного ими раста чего-то стоят.

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

там в целом поциент слюной через сообщение брызжет

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

Зачем тебе помнить название сущностей, если они написаны в коде?

А если ты написал этот код, но написал непонятно и не оставил комментариев (на случай совсем сложной логики), то твой код - говно, а ты - быдлокодер.

Что, в принципе, не удивительно, учитывая твои поливановские девиации.

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

не означает, что миллионы пользователей по всему миру с этим согласны.

Ты не поверишь, но миллионы пользователей(5% стима) по свему миру с этим согласны 😁

Хочешь нормальную юникс-систему?

Хочцу.

Вон иди в магазин

Нихочцу.

покупай мак

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

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

А нормальная юникс-система может не бить прибита к одному набору железа от одного производителя?

это SunOS(Solaris). нормальная система.

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

Раст делает это через костыли вроде unsafe.

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

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

Rust позволяет делать всё то, что и Си, включая прямую работу с железом и написание ядер ОС.

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

Ты не поверишь, но миллионы пользователей(5% стима) по свему миру с этим согласны 😁

SteamDeck подходит под категорию встраиваемой железки, а не десктопа. Там сразу открывается Steam и собственно Линуксом пользователь не пользуется.

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

Многие юзеры линукса не пользуются линуксом (ядром, что ли?) напрямую. Обычно они пользуются какими-то гуи-оболочками.

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

Слушай, ты же профессиональный программист? На зарплате? А можно узнать что ты пилил? В каких объемах в какой срок? Как часто возвращался к коду своему?

Можно на гитхабе глянуть пример твоего кода с комментариями? Мне просто любопытно.

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

Да знаю я что он разраб. Разрабы хайку — люди неглупые и старательные, щяз бы с ними сраться, «2017 век на дворе» (ц)

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

Хомяки больше начинают вливаться в линукс, когда айбиэм/рх ч0т0-там вечно «стандартизирует», как вяленд и сустемду.

Вот и знай теперь, — пользуются / не пользуются — это хорошо или плохо???…

Возможно лунипс должен оставаться той нишевой вещью, «ради безопасТности Здравого Смысла»

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

я пропачил твой код и терь он работает как положено, на!

.— vbr.c 2026-04-25 18:56:35.611473699 +0700
.+++ vbr2.c 2026-04-25 18:58:10.361070372 +0700
@@ -1,15 +1,16 @@
#include <stdio.h>

.-int main(int argc, char *argv) {
.- int n1 = argc;
.- int n2 = 2147483647;
.- int n3 = n1 + n2;
.- printf(«%d», n1);
.+int main(int argc, char **argv) {
.+ unsigned int n1 = argc;
.+ unsigned int n2 = 2147483647;
.+ unsigned int n3 = n1 + n2;
.+ printf(«%u», n1);
if (n1 < n3) {
printf(" < «);
} else {
printf(» >= «);
}
.- printf(»%d", n3);
.+ printf(«%u», n3);
printf(«\n»);
.+ return 0;
}

$ gcc -ovbr2 -O0 vbr2.c
$ ./vbr2
1 < 2147483648
$ gcc -ovbr2 -O3 vbr2.c
$ ./vbr2
1 < 2147483648

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

и вообще вот твоя программа в нормальном си-стиле (естно с исправлениями), а не в этом твоём соевом на 100500 строк:

#include <stdio.h>

int main(int argc, char **argv) {
unsigned int n1 = argc;
unsigned int n2 = 2147483647;
unsigned int n3 = n1 + n2;
printf(«%u %s %u\n», n1, (n1<n3?" < «:» >= "), n3);
return 0;
}

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

ну я как бы в курсе. я прекрасно понял, что он там тут втуляет.

и парирую это тем, что он просто плохо предметом владеет, а туда же.

сопсна Жберт уже всё написал.

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

Да, да, прохладные истории... У меня есть Стим Дек, я лучше знаю. А еще скоро зарелизят Стим Машину(GabeBox), 5% за пару лет может превратится и в 25%. Что тогда будешь чирикать?

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

Вся беда в том, что пользователи стим-дэка — ненастоящие линуксоиды, а кетэйзская подделка.

Нам будет лучше, если таких «Пользователей» будет как можно меньше.

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

Вот это суперпозиция, однако.

«Почему никто не пользуется Linux?! Windows – это полный мусор, а Mac – прибитый гвоздями и клеем обрубок FreeBSD!!»

Вся беда в том, что пользователи стим-дэка — ненастоящие линуксоиды, а кетэйзская подделка.\nНам будет лучше, если таких «Пользователей» будет как можно меньше.

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

А еще скоро зарелизят Стим Машину(GabeBox), 5% за пару лет может превратится и в 25%. Что тогда будешь чирикать?

Можете ещё про Android вспомнить. Только это не тот самый Линукс.

Есть большая разница между десктопным Линуксом по стандартам freedesktop.org и игровой приставкой на базе Линукса.

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

Можете ещё про Android вспомнить. Только это не тот самый Линукс.

Нет, СтимОС — это тот самый Линукс. Просто с иммутабельным корнем.

Есть большая разница между десктопным Линуксом по стандартам freedesktop.org и игровой приставкой на базе Линукса.

Ну, и в чем же она?

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

Для установки на десктоп Линукс вообще не предназначен.

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

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