LINUX.ORG.RU

Новые серьезные уязвимости в ядре Linux и systemd

 


0

1

CVE-2021-33909 – проблема связана с неправильной обработкой длины имени файла. У пользователя есть возможность выполнить код с root-правами.

https://access.redhat.com/security/cve/cve-2021-33909

CVE-2021-33910 – проблемы со стеком, приводящие к падению systemd.

https://access.redhat.com/security/cve/CVE-2021-33910



Проверено: Shaman007 ()

Ответ на: комментарий от hakavlad

Зависит от того, где произносить слово «линукс». Если ты задаёшь вопрос на выставке Е3 Гейбу Ньювеллу «Скажите, будет ли Half Life: Alyx доступна под Linux?», то всем понятно, что имеется именно система, а не ядро. Если ты говоришь «линукс» на специализированном ресурсе, полном технических специалистов, то Linux это ядро, а система это GNU/Linux (или Android).

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

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

На опеннете написано что это в дефаульт установке ф34, я попросил их научить меня монтировать за пределами политики mnt_t. Походу народ не в теме.

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

Как будто С++ запрещает использовать alloca/strdupa.

В C++ есть инструменты и получше, а в Си другого выхода нет, только страдать и сыпать уязвимостями по всему коду. Код на Си == решето.

X512 ★★ ()

Помню как в 2011 пропаганда пёрла из многих утюжков о неуязвимости, бесплатности, дружелюбности линупса. Было смешно. Там один особо отличался, который бубунту пиарил, уже забыл как там его… Короче, было весело :)

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

В C++ можно сразу посылать за использование голых массивов.

Смотря где :)

Иногда посылают сразу за использование std::array вместо голых массивов…

(Причина по которой могут так делать: std::array требует #include <array>, каждый #include увеличивает время компиляции. Ну и другие есть причины…)

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

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

Обработка ошибок в Rust на нормальном уровне. Чтобы появилась паника, чаще всего нужно постараться. И эти старания будут хорошо видны в исходном коде и не пройдут никакого review.

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

И эти старания будут хорошо видны в исходном коде и не пройдут никакого review

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

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

В таких условиях никакой язык не поможет.

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

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

Единственное, что Rust не переживёт, это unsafe-кода, написанного людьми, которым глубоко плевать на правильность кода. Но, извините, тут вообще никто не поможет. В Java точно так же можно через JNI упасть или память расстрелять, к примеру. Решение для Rust это просто на уровне коммита поставить запрет на unsafe кроме ограниченного круга людей. В этом случае можно как-то жить даже в такой ситуации.

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

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

ИМХО Rust в ядре Linux мало что даст. Тут надо с нуля писать ядро, с внутренним API, заточенным под Rust. А то, что делают - это просто какие-то драйверы будут написаны на Rust. Это, конечно, лучше, чем на C, но принципиально ситуацию не изменит. Есть небольшая надежда на фуксию. Там тоже ядро не на Rust, но там само ядро крохотное, и Rust они адаптировали на раннем этапе.

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

это просто какие-то драйверы будут написаны на Rust

Ну вот в данном случае этого как раз и хватило бы - переписать драйвер ФС на Rust, особенно FUSE которому производительность всё-равно пофик так что можно даже с накладными расходами не париться.

zabbal ★★★★ ()
Ответ на: комментарий от Dog
00:09 aceler@Compy:~ $ df -h
Файл.система                 Размер Использовано  Дост Использовано% Cмонтировано в
/dev/nvme0n1p2                 230G         113G  117G           50% /home
00:09 aceler@Compy:~ $ df -i 
Файл.система                    Iнодов IИспользовано IСвободно IИспользовано% Cмонтировано в
/dev/nvme0n1p2                15278080        317292  14960788             3% /home

Да не то чтобы сильно экзотические требования. Свободные 5Г ОЗУ тоже не бог весть какой разврат.

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

Столлман обидется, он же GNU писал.

Но операционной системы у RMS так и не получилось. Поэтому:

Linux is a family of open-source Unix-like operating systems based on the Linux kernel.

https://en.wikipedia.org/wiki/Linux

И несколько несомненно важных GNU-утилит не меняют название семейства OS, как это хочет RMS.

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

Дырявый Си опять в своём репертуаре. А C++ они использовать не хотят.

Лучше уж D в режиме betterC, там нормальная рефлексия и нормальное метапрограммирование есть, в отличии от.

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

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

Нет никакого «как», паника это и есть исключения, названные иначе. Исключения были одной из причин, по которым С++ не прошел в ядро.

Первый вариант это делать моментальный abort

Очень интересное ядро получается.


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

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

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

Попробуй это переписать на кресты без alloca и без выделений на хипе https://wandbox.org/permlink/QSe51o1Mt6kuuBNg

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

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

В C++ по-другому. Сначала ищется обработчик. Если он найден, раскручивается стек до него. Если не найден, стек не раскручивается (implementation defined, но именно так реализованно в gcc и clang), а зовется std::terminate.

rupert ★★★★★ ()