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 ()
Последнее исправление: cetjs2 (всего исправлений: 3)

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

GNU/Linux

там из GNU уже glibc только. по историческим причинам GNU. и то поттер порывается ее переписать. systemd/Linux будет вернее.

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

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

Что такое голый массив?

Если есть голый, то должен быть одетый массив)))

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

несколько несомненно важных GNU-утилит

Несколько десятков (а то и сотен) — если быть более точным. Но основных крупных системных программ в юзерспейсе действительно всего несколько: загрузчик (GNU GRUB), базовые системные утилиты (GNU Core Utils), shell (GNU Bash), компилятор (GCC — GNU CC), библиотека системных вызовов (Glibc — GNU C Library) и ПО для обращения с объектным кодом в объектных файлах (GNU Binutils).

Также следует обратиться к истории. Исторический контекст ведь очень важен. Необходимо знать причину, условия и факторы, при которых образовалась ОС GNU. А это — необходимость в свободной замене Unix.

Факт в том, что сначала была начата разработка операционной системы GNU (т. е. полноценной и самостоятельной ОС), затем стадия разработки дошла до того, что сама свободной системы для замены Unix уже была готова, но возникли сложности с ядром GNU Hurd (из-за его микроядерной архитектуры, которая требует больше аремени и усилий, несмотря на очевидные преимущества). К этому моменту финский студент Линус Торвальдс написал just for fun ядро (как он сам заявлял: «я написал ядро Linux, но это не такой серьезный и крупный проект, как ОС GNU»), а его знакомый опубликовал его на FTP-сервере (с лицензированием под GNU GPL в последствии).

Это стало причиной появления различных дистрибутивов (как Linux и GNU по отдельности, так и систем-франкенштейнов — GNU с ядром Linux).

не меняют название семейства OS

Да, если речь о семействе ОС Linux (Alpine Linux, OpenWrt, Android, — это все в первую очередь; сюда же относятся системы семейства ОС GNU, если они имеют ядро Linux: Debian GNU/Linux, PureOS и т. д.). Таким образом, если у системы ядро Linux, то такую систему называть Linux'ом можно и нужно (точно не будет ошибкой). В этом случае речь будет идти о системе, как принадлежащей семейству Linux. В случае, если система имеет юзерспейс GNU, то ее можно и нужно называть ОС GNU (речь будет идти о семейства GNU). Среди семейства ОС GNU есть системы без ядра Linux (с ядром от GNU — GNU Hurd). Так, например, GuixSD — дистрибутив не только GNU/Linux-системы, но и ОС GNU, т. к. из него на выбор можно развернуть как систему семейств GNU/Linux и Linux, так и ОС GNU. Во втором случае можно уточнить в названии: ОС GNU + GNU Hurd или GNU (Hurd). К системам семейства GNU относятся как чисто GNU-системы (GuixSD, Debian GNU/Hurd, Arch Hurd и т. д.), так и GNU с ядром Linux или kFreeBSD (Ubuntu, Fedora и т. д.).

Таким образом, одна операционная система может относиться сразу к двум семействам (или подсемействам — в зависимости от классификации). Здесь имеем дело с ложной дихотомией.

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

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

anonymous
()

Эти ваши сусмудэ и пышьаудио мне столько кровки попили, что ололо. Почему у меня наушники не работают в дискорде?! Дизлайк и отписка. Красная шляпа - корпорация зла.

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

Не напоминай. Я из-за пшпшаудио в 2009 чуть назад на венду не вернулся. Эту хрень пропихнули насильно во всякие убунты тогда. У тебя в дискорде наушники не работают, а у меня тогда в фильмах и музыке звук прерывался постоянно на несколько секунд, но зато на каждом форуме фанатики кричали «вы ничо ни панимаити, так и должно быть!». Хорошо, я, тогда еще неопытный, догадался все ж отключить эту гадость и использовать чистую альсу. Тогда я удивился, насколько чистым и хорошим может быть звук в линуксе. С тех пор никаких пшпшаудио. Хотя ее, говорят, закопали уже

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

Понимаешь в чём дело. PulseAudio внедрили, включив его в дистрибутивы по умолчанию, и не предоставив настолько же простого способа выключить, какой был у ESD и aRts (в KDE Control Center заходишь в Sound и просто убираешь галочку «Use sound server»). Фактически это был подход советской обязаловки, когда всем сказали сдавать говно, и все пошли сдавать. При этом ты имеешь право отказаться сдавать говно, но тогда тебе скажут «чел, нам и самим это не нравится, только это уже стало нормой, и все это делают. А если ты не хочешь, значит ты против общества, значит ты против нас».

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

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

Скорее наверное без ручного управления памятью.

В С все аллоцируется на стеке потому что это единственный Raii, который там есть. Стек очистится сам.

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

А если динамической памяти нет, или нужна производительность - есть арены и polymorphic memory resource, что опять сильно упрощает работу с памятью позволяя сосредоточиться на реальных проблемах.

В-третьих, есть хорошо отлаженные стандартные алгоритмы. Используя их уже на 99,99% снижается вероятность улететь за пределы контейнера. Опять же можно сфокусироваться на решаемой проблеме, а не на условии выхода из цикла.

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

вторая уязвимость в systemd.

Пора уже переименовывать в linuxd, всё равно эта вундервафля только на линуксе работает.

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

Как ты будешь динамичеки довыделять, если 512 не хватило, но до переполнения стека еще далеко?

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

Да никак. Не спорь с ними :-Д Мамкиных экспертов не переубедить.

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

признать, что линукс потрачен.

что у вас за новый мем с этим «потрачено» появился?

Да надо уже ядро в kerneld переименовать

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

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

Серьёзная победа си над C++ — в C++ невозможно воспроизвести сишные баги.

Ну вообще-то твой std::byte buffer[512]; вполне себе может переполнить стек, например в ситуации, когда у тебя этот самый стек заканчивается, и выделение 512 байт его как раз переполнит.

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

что у вас за новый мем с этим «потрачено» появился?

Это из кривого пиратского перевода GTA San Andreas

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

что у вас за новый мем с этим «потрачено» появился?

Да это старый мем, вообще-то. Из GTA San Andreas с кривой русификацией промтом. Там, когда тебя убивают, появляется надпись «Wasted», которую перевели как «Потрачено». «Охладите трахание» и «Она со мной, углепластик» оттуда же.

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

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

Я все правильно написала.

«We successfully exploited this uncontrolled out-of-bounds write, and obtained full root privileges on default installations of Ubuntu 20.04, Ubuntu 20.10, Ubuntu 21.04, Debian 11, and Fedora 34.»

https://www.qualys.com/2021/07/20/cve-2021-33909/sequoia-local-privilege-escalation-linux.txt

Djanik
() автор топика
Ответ на: комментарий от CaveRat

подвержены только некоторые версии

Debian 11, Fedora 34, Red Hat Enterprise Linux (RHEL) 6, 7 и 8. а также в Ubuntu версий 20.04, 20.10 и 21.04.

Это ты называешь «некоторые версии»?

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

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

Любая операция деления, любая операция получения памяти, …

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

Я первый про stack overflow написал :P

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

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

anonymous
()

The issue results from not validating the size_t-to-int conversion prior to performing operations

Хаха. Спасибо кулхакерам из Bell, которые думали что слабая типизация - это хорошо для системного языка. Таких мин в сишном/плюсовом софте 100500, только копни.

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

Полная чушь.

: в сях все буфера на стеке делаются,

4.2

первых, из-за того, буферы там не надо аллоцировать, это просто делать на куче.

Так не надо аллоцировать, или просто делать на куче? Кто помешал делать malloc в С – непонятно.

Не надо сразу все переменные в начале функции объявлять

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

Более того, у С и С++ один компилятор. Различаются у них только фронтенды.

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

на специализированном ресурсе, полном технических специалистов

Имеет ли право токарь или слесарь использовать доску, если электрик забыл перчатки? Большинству «технических специалистов» ваша «писанина» не впёрлась никуда, потому что они используют гораздо более удобное. Извенити )

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

Так не надо аллоцировать, или просто делать на куче?

Ключевое слово «там» == «на стеке». Потому что это легко сделать на куче. Отсюда ответ на твой следующий вопрос:

Кто помешал делать malloc в С – непонятно.

Сложность всей этой процедуры. Надо следить за аллокацией, надо следить за деаллокацией. Особенно тяжело следить за деаллокацией при обработке ошибок чтобы не обоссаться (протечь). Это намного более кропотливая работа, чем повсюду пихать char buf[MAX_SIZE]. Которую на себя берет компилятор.

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

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

Какой феерический бред. Иди учи матчасть.

Более того, у С и С++ один компилятор. Различаются у них только фронтенды.

Иди учи матчасть дальше. Вообще не понимаешь, о чем пишешь. Frontend - это как раз то, что отличает один яп от другого.

anonymous
()

да то как же

CVE-2021-33909 The issue results from not validating the size_t-to-int conversion prior to performing operations.

«С» не виноват, виноваты линугсойды г0вн0к0деры. Кресты от них не спасут. Каждый раз смотрю на эти линуксойдные макароны с говнокодом и плююсь. Печально, что все российские ОС из этого сделаны.

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

нет-нет, меня волнует именно линукс.

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

У пользователя есть возможность выполнить код с root-правами.

У какого-то пользователя есть возможность выполнить какой-то код от имени рута. Даже не сказано, что произвольный. Разве это не так?)

А вообще, язабан, конечно.

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

Сложность всей этой процедуры. Надо следить за аллокацией, надо следить за деаллокацией. Особенно тяжело следить за деаллокацией при обработке ошибок

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

Я-то на С пишу, а вот на твой счет не уверен. Если выделение памяти на буфер вызывает такие сложности, страшно представить, что случается при работе в предметной области.

Frontend - это как раз то, что отличает один яп от другого.

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

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

«чаще всего». Ты написал исключения из правил. А что ты предлагаешь? Каждую операцию деления и получения элемента массива возвращать в виде Optional? Это просто неразумно.

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

Нет никакого «как», паника это и есть исключения, названные иначе.

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

Исключения были одной из причин, по которым С++ не прошел в ядро.

Единственная причина, по которой С++ не прошёл в ядро, это предпочтения Линуса. В другие ядра С++ прекрасно прошёл и никаких проблем это не вызвало. В gcc (и во всех других известных мне компиляторах C++) исключения отключаются одним флагом.

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

Да ровно такое же, как сейчас. FAQ/BUG почитай. Ну ладно, не как сейчас, чуток надёжней, конечно, как ни крути.

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

А в Java нет никакого std::terminate, там всегда раскручивается до конца. Если завершился главный поток, то распечатывается stacktrace. Если не главный, то ничего не распечатывается ЪУЪ

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

Да ровно такое же, как сейчас

…не считая того, что panic! вызывается на всякую чушь.

Единственная причина, по которой С++ не прошёл в ядро, это предпочтения Линуса

Ну раз так, то, наверное, и драйвер в ядро приняли с паникой, и не пришлось std переписывать?

Паника похожа на исключения, но имеется ряд отличий.

Никаких отличий не существует, кроме как с пользовательской точки зрения.

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

Каждую операцию деления и получения элемента массива возвращать в виде Optional? Это просто неразумно.

Внезапное падение программы разумней? Вспоминается perl с его save() || die "Cannot save your data";

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

Я-то на С пишу, а вот на твой счет не уверен.

Конечно же нет. Я не настолько упорот. Было бы интересно посмотреть, что там такого крутого написал.

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

Именно. в C только и занимаешься тем, что следишь за выделением памяти. Никакой предметной области.

Вообще я почитал подробности этих CVE - прям как в воду глядел. Аллокации на стеке под буферы, лишь бы не париться с деаллокацией.

И то, где этот косяк вылез - вообще смешно. В плюсах сто лет есть boost.filesystem, а теперь и стандартная.

И вот даже посмотреть, как «исправили» (код с гитхаба) -

       p = strdup(f);
        if (!p)
                return -ENOMEM;

        path_simplify(p);

        if (empty_or_root(p))
                s = strdup("-");
        else {
                if (!path_is_normalized(p))
                        return -EINVAL;

все - обоссались, если путь не нормализован. Кто p = strdup деаллоцирует? Раньше это dupa и делал.

И вот куда не плюнь - такая хрень вылезает. Еще иксперты такие, «сложности вызывает»…

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

В данном конкретном случае обоссались таки вы. Ибо выше:

        _cleanup_free_ char *p = NULL;

_cleanup_free_ — это макрос, раскрывающийся в __attribute__((cleanup(…))).

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

«I never leak» (c).

Действительно. Там даже в конце TAKE_PTR. Круто!

Говорю, я ж на С не пишу и уж тем более не в курсе всех расширений. Вон, в соседнем топике обсуждали лямбды в С (-fblocks).

Но я всё равно придерживаюсь своего мнения: зачем переизобретать C++, если уже есть готовое и стандартное?

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