Уязвимости в systemd (CVE-2021-3997) и Flatpak (CVE-2021-43860)

тег systemd равнозначен security hole.

Отлично.

Еще один повод ненавидеть ненужноД.

самое смешное тут

Исправление в Fedora и RHEL пока на стадии тестирования, в Ubuntu и Suse уязвимость закрыта.

systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev больше опций богу опций! Кто-то походу забыл про KISS и юниксвей. Давайте еще в cp встроим опцию удаления при копировании или архивацию.

Про KISS там забыли еще на стадии проектирования (если она вообще была)

Когда уже люди наконец осознают, что писать программы без уязвимостей в принципе невозможно: нельзя за конечное время описать бесконечное количество состояний тьюринговской машины. Это как носить воду в решете.

При создании тысяч вложенных каталогов выполнение операции systemd-tmpfiles –remove приводит к аварийному завершению из-за исчерпания стека

Кто-то видимо MISRA не просматривал и не знает, что в критических системах за рекурсию банят из жизни.

Ох, сейчас в комментариях будут полыхания уровня Соловьёва :3

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

странно. а почему у кнута получилось?

Для этого во время загрузки необходимо создать в /tmp большое количество вложенных подкаталогов.

Чет выглядит как отмораживание ушей назло.

При создании тысяч вложенных каталогов выполнение операции systemd-tmpfiles --remove приводит к аварийному завершению из-за исчерпания стека. Обычно утилита systemd-tmpfiles в одном вызове выполняет операции удаления и создания каталогов (systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev), при этом вначале выполняется удаление, а потом создание, т.е. крах на стадии удаления приведёт к тому, что не будут созданы важные для работы файлы, указанные в /usr/lib/tmpfiles.d/*.conf.

Так, еще раз. Чтоб сработало надо при загрузке создать кучу вложенных каталогов. Но первым при загрузке выполняется удаление. Которое падает, если было создано много вложенных подкаталогов. Но их создание происходит после удаления. Как это работает?!

это работает как спагетти-код

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

самое смешное тут

Наверное потому, что не уверены в патче, и этому пропатченному системДэ надо пройти семь кругов ада тестирования, а то вдруг ещё что-либо вылезет.

А может ищут подобные уязвимосте во всём комбайне, дабы одной обновой закрыть уже существующую, и остальные потенциальные дыры.

Просто подход у каноникла и красношляпы к тестированию ПО различается - первым залатать побыстрее, вторым - залатать так, что бы потом не протекло.

В лишнем >миллионе строк кода, созданном с наплевательским подходом к безопасности (см. SystemD Pwnie Award), обнаружилась уязвимость! Какая внезапная новость :P

Есть такой параметр, как средняя вероятность проблем (ошибок, дыр и т.д.) у строки кода. Чем больше строк кода в проекте, тем больше будет таких проблем при прочих равных условиях. И даже если признать что качество кода SystemD соответствует таковому у OpenRC / runit (что будет являться большой натяжкой) - из-за настолько огромного количества строк кода, количество проблем у SystemD будет несравнимо выше. И именно поэтому я выбираю дистрибутивы с OpenRC / runit: заодно выбирать проще и дистрохоппинга меньше: т.к. достойных дистрибутивов, устоявших перед соблазнами RedHat, к сожалению немного.

решето!

хорошую поделку системГ не назовут.

еще в cp встроим опцию удаления при копировании

есть же mv… хотя да, тогда последнюю можно выпиливать [ОДОБРЕНО]

или архивацию.

что-то такое есть, кажется

Кода без багов не бывает.

при прочих равных кол-во багов растет к кол-вом кода.

у системГ уже объемы исходников равны объему исходников ядра версии 2.4 и оно все пухнет и пухнет…

позволяет при загрузке пакета из непроверенного репозитория

Но ведь линуксоиды не ставят пакеты с васяносайтов, как тупые вендузятники. Ведь так? Так?

ага, флатпак прям как раз для этого.

Так

systemd и flatpak используют только латентные виндузатники

Возможно. Но это дорого и долго.

думать головой это дорогая операция, да.

Возможно. Но это дорого и долго.

Бесконечно долго и бесконечно дорого.

Ваш борщ стынет, капитан, проследуйте на кухню.

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

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

Также обнаружена уязвимость в sysvinit — в init.d можно создать скрипт, содержащий rm -rf /*, приводящий к отказу в обслуживании.

ой

гомотопическую теорию типов

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

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

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

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

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

Наверное потому, что не уверены в патче

У них всегда так, а у людей работа стоит и надо самим патчить да залатывать, например недавно меса сломали hd620, и ни они, ни дистрибутивы (федора) патчить ничего не хотят, хотя патч есть и работает, но надо понимаете ли подумать, посидеть как бы так красивее. И это ««««stable»»»» (fedora, mesa)

вторым - залатать так, что бы потом не протекло.

это надо системд выпиливать…

Бесконечно долго и бесконечно дорого.

Это пытаться что-то доказать дураку.

И то верно.

Про число багов на 1000 строк говорить можно. Про число дыр на 1000 строк говорить нельзя. Это разные вещи. У тебя может быть миллион строк, выполняющихся в процессе без привилегий и 1000 строк в процессе с рутом. А может быть сто тысяч строк в процессе с рутом. Во втором случае баги с бОльшей вероятностью будут уязвимостями. В общем всё зависит от архитектуры.

Зачем тебе срочно залатывать эту дыру? Кто там у тебя в /tmp создаёт иерархии? По сути уязвимость больше теоретическая. Пофиксить надо, а разводить из-за этого панику не надо.

самое смешное тут

Нет, самое смешное, что systemd-tmpfiles (как и elogind) используется даже в генте с openrc (т.е. «без systemd»).

вот это поворот

А ещё там используется bash, где с рутовыми правами тоже можно поломать систему.

как пример DJB

Бернштейн? Автор qmail. Даже не смешно
https://www.openwall.com/lists/oss-security/2020/05/19/8
выполнение любого кода от любого пользователя (кроме root) если правильно сформировать письмо

systemd - говно! Зато на нем огурцы хорошо растут, да и программ без ошибок не бывает!

С этой ладно, я в целом про тенденцию «стабильных» версий в опен сорсе, btw flatpak тоже сразу обновился, и тоже ничего не фиксят, получается что надо самому чинить/откатывать это все в нескольких местах, даже если например сам дистр стабильный.

Про тот как так вышло была целая серия тредов под названием gentoo exodus, tldr как обычно системдшники внедрились в проект

самое смешное тут

Исправление в Fedora и RHEL пока на стадии тестирования, в Ubuntu и Suse уязвимость закрыта.

Не удивлён. Когда я репортил уязвимость с примером тривиального эксплойта в популярном пакете на их общий с RHEL ящик, то они уточнили «аффектится ли RHEL?». Узнав, что уязвима только Fedora – просто забили болт на месяца два точно, дальше не следил.

Canonical же тогда выкатила патч уже через сутки или даже меньше от момента получения письма. За несколько лет до того репортил им ещё local root уязвимость в Ubuntu-специфичном пакете, и тоже всё прошло отлично: они не только пофиксили моментально, но и их разраб вышел на меня в чате пообщаться.

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

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

As a proof of concept, we developed a reliable, local and remote exploit against Debian’s qmail package in its default configuration. как говорится, найдите в чём проблема и кто не осилил собрать нормально.

Про KISS там забыли еще на стадии проектирования

Про BDUF

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

если вы чего-то не знаете, то это не значит, что: это невозможно, этого нет

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

Товарищ выше, вон, даже про «вероятность» ошибки в коде говорит? Это ли не смешно? Да как бы это вообще было возможно, будь наши программы 100% детерминированными? Вы сами-то себя слышите, господа программисты? Вероятность ошибки в коде! В системе, где основой всего является бит с двумя весьма конкретными значениями. Это же не квантовые вычисления. Как такое вообще могло произойти? А может быть мы просто не можем просчитать все возможные варианты развития событий в программе? И что же нам мешает это сделать?

вы берёте максиму чтобы оправдать свою безграмотность

Ну это да :)

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