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

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

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

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

Запретить имена файлов.

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

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

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

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

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

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

зачем

Лизка.

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

Linux, скорее всего подразумевая ядро

Пора уж привыкнуть, что линукс - семейство ос.

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

Как будто Rust запрещает использовать unsafe.

К чему этот бред – непонятно.

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

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

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

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

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

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

Код прошел ревью. Проблема в тех, кто его проводил, а не в С.

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

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

Системда что не на с++ ? Патрик оказывается в си могёт.

Где там C++?

А с++ во все платформы могёт, что и Си ?

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

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

Смотря где :)

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

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

Использовать платформы, которые не поддерживает компилятор C++ – ССЗБ. Хватит из помойки тащить железо

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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Г ОЗУ тоже не бог весть какой разврат.

Столлман обидется, он же 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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