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

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

anonymous ()

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

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

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

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

anonymous ()

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

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

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

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

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

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

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

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

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

drfaust ★★★★★ ()

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

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

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

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

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

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

anonymous ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

как пример DJB

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

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

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

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

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

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

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

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

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

anonymous ()