LINUX.ORG.RU

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

 , , ,


2

1

В systemd-tmpfiles выявлена уязвимость, позволяющая вызвать неконтролируемую рекурсию и отказ в обслуживании системы. Для этого во время загрузки необходимо создать в /tmp большое количество вложенных подкаталогов. Исправление в Fedora и RHEL пока на стадии тестирования, в Ubuntu и Suse уязвимость закрыта.

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

Уязвимость во Flatpak позволяет при загрузке пакета из непроверенного репозитория через манипуляции с метаданными скрыть использование повышенных прав. Еще одна уязвимость без CVE позволяет во время сборки пакета командой flatpak-builder --mirror-screenshots-url создать каталоги в ФС за пределами сборочного каталога.

>>> CVE-2021-43860

>>> CVE-2021-3997



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

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

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

untitl3d
()

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

cocucka ★★★★☆
()

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

anonymous
()

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

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

PPP328 ★★★★★
()

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

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

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

anonymous
()

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

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

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

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

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

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

anonymous
()

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

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

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

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

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

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

drfaust ★★★★★
()

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

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

SakuraKun ★★★★★
()

решето!

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

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

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

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

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

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

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

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

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

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

anonymous
()

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

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

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

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

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

Так

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

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

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

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

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

anonymous
()

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

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

Irben ★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

gremlin_the_red ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Про BDUF

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

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

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

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

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

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

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

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

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