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 ()

Написано, что обе уязвимости в Linux, скорее всего подразумевая ядро. Однако, судя по описанию, первая уязвимость в линукс, а вторая уязвимость в systemd.

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

Однако, судя по описанию, первая уязвимость в линукс, а вторая уязвимость в systemd.

По ссылкам все так и есть

CaveRat ★★ ()

Systemd говорят штабильно!

ggrn ★★★★★ ()

Серьезные, my ass.

Обе требуют локального доступа к системе, дыра в ядре помечена как «attack complexity = high», в настоящий момент подвержены только некоторые версии.

CaveRat ★★ ()

Про первую уязвимость, которая якобы «код c root-правами»

leading to a system crash or a leak of internal kernel information.

Зачем напрямую искажать информацию?

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

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

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

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

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

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

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

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

X512 ★★ ()

Проблемы systemD это проблемы systemD.

anonymous ()

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

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

Если под всеми подразумевается хайку то да.

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

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

Смотря где :)

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

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

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

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

Я не говорил про std::array. Есть много вариантов в том числе без динамического выделения памяти.

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

Не хватает разработчиков и мотивации это называется. Ничего не мешает перенести Haiku на весь зоопарк платформ.

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

Чтобы от малейшей ошибки init процесс падал? Rust толком не умеет ни исключений, ни кодов ошибок, там паники повсюду.

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

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

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

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

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

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

fernandos ★★★ ()

Астрологи объявили месяц уязвимостей в Lineux. Количество новостей про «решето» увеличено в разы.

Nodrog ()

А где драма про PID1? Срача мало будет.

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

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

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

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

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

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

Legioner ★★★★★ ()

Молодцы, конечно, разработчики systemd что всё-таки шлёпнули заглушку на косяк в ядре. Но по факту обе уязвимости это следствие проблем ядра - скорей бы уже туда и в gcc притащили rust.

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

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

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

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

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

zabbal ★★★★ ()

Сисямбда как обычно.

Dog ()

Справедливости ради, хоть системд и остается говном, но эксплоит на сабжевую уязвимость треюует 5гб ОЗУ и 1 млн свободных inode на целевой системе.

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

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

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

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

Не хватает разработчиков и мотивации это называется

Лицензии BSD и MIT вообще не оч с мотивацией.

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

Давно пора systemd переписать на Rust.

вот был бы он размером с нормальный init - возможно. а теперь уже опаньки.

crypt ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.