LINUX.ORG.RU
ФорумTalks

очередной not-a-bug

 ,


1

2

Копипаста в опеннета

В системном менеджере systemd выявлена уязвимость (CVE-2020-1712), которая потенциально позволяет добиться выполнения своего кода с повышенными привилегиями через отправку специально оформленного запроса по шине DBus. Проблема исправлена в тестовом выпуске systemd 245-rc1 (решающие проблему патчи: 1, 2, 3). Уязвимость устранена в дистрибутивах Ubuntu, Fedora, RHEL (проявляется в RHEL 8, но не затрагивает RHEL 7), CentOS и SUSE/openSUSE, но на момент написания новости остаётся неисправленной в Debian и Arch Linux.

Уязвимость вызвана обращением к уже освобождённой области памяти (use-after-free), возникающем при асинхронном выполнении запросов к Polkit во время обработки DBus-сообщений. Некоторые DBus-интерфейсы используют кэш для хранения объектов на короткое время и очищают элементы кэша как только шина DBus освободится для обработки других запросов. Если обработчик DBus-метода использует bus_verify_polkit_async(), ему возможно потребуется ожидать завершения действия в Polkit. После готовности Polkit обработчик вызывается повторно и обращается к уже ранее распределённым в памяти данным. Если запрос к Polkit выполняется слишком долго, то элементы в кэше успевают очистится до того, как обработчик DBus-метода будет вызван второй раз.

Из сервисов, позволяющих эксплуатировать уязвимость, отмечается systemd-machined, который предоставляет DBus API org.freedesktop.machine1.Image.Clone, приводящий к временном сохранению данных в кэше и асинхронному обращению к Polkit. Интерфейс org.freedesktop.machine1.Image.Clone доступен всем непривилегированным пользователям системы, которые могут инициировать крах сервисов systemd или потенциально добиться выполнения кода с правами root (прототип эксплоита пока не продемонстрирован). Код, позволяющий эксплуатировать уязвимость, был добавлен в systemd-machined в 2015 году в версии systemd 220 (в RHEL 7.x используется systemd 219).

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

Но другой реализации у нас нет. Выпихнули логику из скриптов в сам инит, и там завелся лапшекод. Немного предсказуемо.

runit, openrc, shepherd … были еще какие то, но это те что на слуху.

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

сам сервис не отключить, да. Можно отключить ведение лога

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

я ведь даже не знаю на какой стадии эта проблема
мне приходится сперва решать проблему с самим systemd
где смотреть логи?

Ну, с такими умственными способностями тебе стоит дальше продолжить развозить хлеб

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

давайте оставим в покое

Но вам с лопаты приносят очередной наброс про systemd, и вы с радостью бежите кидаться говном)

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

в то время как альтернативные решения нет

На «альтернативные решения» всем настолько насрать, что в них даже уязвимости не ищут

Deleted
()

Э, а при чём тут not-a-bug, или Лёня опять заявление сделал, что это фича?

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

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

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

там есть dbus

да, единственный вменяемый ipc в линуксе, тут ничего не поделаешь

веб-сервер и кучу другого того что в ините и быть не должно?

всё это либо отключается на этапе сборки, либо просто отключается (systemctl disable) соответствующий юнит. у меня например ничего из этого нет

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

Но вам с лопаты приносят очередной наброс про systemd, и вы с радостью бежите кидаться говном)

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

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

На «альтернативные решения» всем настолько насрать, что в них даже уязвимости не ищут

ага ага, расскажи. сколько в других инитах, ну или в том же sysV ините было дыр?

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

Аргументы?

сам подумай, реализовано поверх unix socket-ов, через отдельный юзерспейс процесс, в следствие чего куча контекст свитчей и копирований.

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

сам подумай, реализовано поверх unix socket-ов, через отдельный юзерспейс процесс

Твои варианты, как сделать что-то с семантикой D-Bus без «отдельного юзерспейс процесса»?

Если втащить D-Bus в ядро, ты же первый завоешь про вендорлок, монолит и редхатовскую закулису.

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

Твои варианты, как сделать что-то с семантикой D-Bus без «отдельного юзерспейс процесса»?

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

Если втащить D-Bus в ядро, ты же первый завоешь про вендорлок, монолит и редхатовскую закулису.

я про закулису тут никогда не вещал, вендорлок да, тк это и есть вендорлок, хотя и такой себе. в ядро тащить это не надо да.

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

Ему про Фому, а он про Ерёму… Не надо DBus никуда втаскивать. Его надо выбрасывать, ибо есть и более адекватные решения (ubus, например). Ну или можно допилить bus

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

а где смотреть логи? зачем их сделали бинарными?

Ставшь rsyslog и отправляешь логи в том числе и туда. И радуешься жизни.

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

А сейчас есть не менее добрый и куда более удобный journalctl.

Ну хз. Для машинной автоматизации удобен. Пользователю человеку не очень.

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

а systemd такая шляпа

Что пропихнута много где и знать его нужно будет.

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

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

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

А системд на такое способен?

Способен. Особенно во всяких дебианах и убунтах, у которых старые скрипты обёртки.

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

домохозяйка … будь у неё bash-портянка

Поделил на ноль.

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

systemd норм был бы, но к нему жирная претензия, что он работает только на линуксах. Вот это не норм уже.

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

Каст не работает

Потому что markdown разметка вместо лоркода и каст там по другому делается. Надо замечать что происходит вокруг.

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

unit’ы декларативные это благо, которое боженька с неба спустил

Да, не без этого. С декларативными проще, конечно.

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

Если конечно journald не отключили

Чтобы между перезагрузками работало, нужно его ещё персистентным сделать, что вполне неочевидно, сталкиваешься уже по факту, когда надо посмотреть логи того, что было до перезагрузки, а журнал не персистентен. Как можно сделать по умолчанию логи не персистентными, я не понял. То есть не понял почему так сделали.

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

То есть не понял почему так сделали.

Потому что слишком много истеричек вопило «ааа, нам пропихивают журналд».

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

нечитаемую bash-лапшу вместо аккуратненьких скриптов … Python

Спасибо, посмеялся. В баше скрипты чем неудобны, что вместо потоков там форкаться надо, поэтому некоторые проблемы имеются. А так там вполне аккуратно пишется. Но если человек на баше написал лапшу, можешь не соменваться, на питоне у него тоже лапша будет.

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

озвучь задачи для этого IPC

  • условная аутентификация в зависимости от содержимого сообщения (то, что сейчас dbus+polkit)
  • активация процесса по запросу (при отправке ему сообщения)
  • рассылка событий мультикастом

но мне не понятно зачем нужен этот dbus в системе инициализации

По тем же пунктам:

  • чтобы я мог от пользователя сделать systemctl start foo, но не мог systemctl stop bar (разумеется, без костыляния своих обёрток, в которых вероятность налажать при разборе аргументов — 100%)
  • чтобы всякие не всегда нужные демоны запускались только когда они нужны, и не жрали батарейку всё оставшееся время
  • чтобы приложения могли следить за тем, что происходит в системе (разумеется, без поллинга, в котором вероятность налажать и допустить race condition — 100%)

Достаточно?

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

Не надо DBus никуда втаскивать. Его надо выбрасывать

Потому что ты так сказал?

есть и более адекватные решения (ubus, например)

«Компьютеры надо выбрасывать — есть и более адекватные решения (счёты, например)».

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

Потому что слишком много истеричек вопило «ааа, нам пропихивают журналд».

Так он же и так пропихнут, при этом не персистентент.

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

Проблема в том, что десктопный стек вокруг dbus (polkit, сам dbus, штуки для трекинга сессий, клиентские библиотеки) сосет такой писюн, что хочется рыдать.

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

в которых вероятность налажать при разборе аргументов

Кхе-кхе, в systemd уже пару раз налажали в разборе и отказались чинить :)

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

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

чтобы приложения могли следить за тем, что происходит в системе (разумеется, без поллинга, в котором вероятность налажать и допустить race condition — 100%)

Это ништяк, тока зачем это действительно в системе инициализации? Опять же, все скатывается к тому, что systemd не инит, а маленький такой core-дистрибутив (примерно как util-linux, только от мира server-side).

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

Кхе-кхе, в systemd уже пару раз налажали в разборе и отказались чинить :)

Где?

Сам по себе болтающийся процесс особо ничего не ест

Неправильное обобщение.

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

Это ништяк, тока зачем это действительно в системе инициализации?

Зачем системе инициализации иметь средства интроспекции и в частности позволять другим программам получать список того, что запущено? Действительно, зачем. Деды парсили /proc и мы будем.

systemd не инит

https://github.com/systemd/systemd — не инит. https://github.com/systemd/systemd/tree/master/src/core — инит.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 6)
Ответ на: комментарий от eternal_sorrow

В любом софте есть уязвимости и если в твоей любимой программе их не находят - значит плохо ищут.

Хера, ты прописал всех прогеров в лютые говнокодеры )))

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

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

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

Как будто что-то плохое

Дийкстра-то был тот ещё воинствующий илитарий.

Без воинствующих ылитариев системд и получается.

xxx: yyy, do you think it would be possible to generate 1 Shader Binding header file per Shader ? Currently if you add a new texture to a shader half of the engine has to be recompiled…

yyy: X Y problem.

yyy: Your real issue is the fact that half of the headers are «leaking» not the fact that bindings are in one file. And this problem should be solved by fixing leaking not workarounding by splitting.

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

как

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

почему это лучше

без сервиса посредника + возможность обратной связи (полный асинхронный дуплекс).

deep-purple ★★★★★
()
Последнее исправление: deep-purple (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.