LINUX.ORG.RU

В systemd 228 обнаружена локальная root-уязвимость

 , ,


2

2

Проблема присутствует в кодовой базе systemd только в выпуске 228 и была около года назад без лишней огласки устранена в выпуске 229

При этом явно данная проблема уязвимостью помечена не была и не выделялась в общем потоке изменений. В примечании к исправлению указано, что исправленная ошибка может привести к DoS-атаке через исчерпание дискового пространства в разделе через заполнение файла /run/systemd/show-status, созданного с правами 07777.

Спустя год на исправление обратили внимание разработчики дистрибутива SUSE, которые пришли к выводу, что указанная ошибка не ограничивается отказом в обслуживании и может легко быть использована для получения root-доступа в системе.

http://www.opennet.ru/opennews/art.shtml?num=45908

★★★★

Сегодня праздник у sd-отрицательных!

Harald ★★★★★ ()

Поттеринг офигел

Не надо так пугать заголовками. Я уж сходу подумал что он очередную подсистему отлаженную за десятилетия решил включить в свою поделку. А тут всего-лишь какая-то рут уязвимость ...

DawnCaster ()

Ну так исправил же.
Так что норм всё.

Goury ★★★★ ()

Интересно, бывали ли в других инитах такие дыры вообще?

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

Но Поттеринг же все равно офигел.

Не, все как обычно.

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

Ну так где-то может крутиться уязвимая версия, которую обновить нельзя/невозможно/забыли (нужное подчеркнуть).

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

Так что норм всё.

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

Хорошо если это произошло лишь по халатности и разгильдяйству, а если он намерено не указал на возможные последствия эксплуатации данной уязвимости?

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

Шеллшок пойдёт?

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

hateyoufeel ★★★★★ ()

Проблема присутствует в кодовой базе systemd только в выпуске 228 и была около года назад без лишней огласки устранена в выпуске 229

Братишка, я тебе новый systemd принёс.

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

Хорошо если это произошло лишь по халатности и разгильдяйству

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

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

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

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

Ну он может просто доботрах малолетний.
А ты почему не указал?

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

Я так понял, в сусе ковыряли что бекпортировать и наткнулись на эту бяку. Было бы явно указано на опасность, то это бы бекпортировали в первую очередь.

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

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

Полностью оправдано. Мейнтейнеры, тащащие в стабильный дистрибутив нестабильные поделки ССЗБ.

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

Было бы явно указано на опасность, то это бы бекпортировали в первую очередь.

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

Мейнтейнеры, тащащие в стабильный дистрибутив systemd-поделки (разработчики которого плевать хотели на безопасность) ССЗБ.

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

Шеллшок пойдёт?

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

Ладно, пока я пишу эксплойт, чтобы не скучать, можешь поизучать https://www.google.ru/search?q=rhel initscripts security advisory

н-р https://tools.cisco.com/security/center/viewAlert.x?alertId=10535 и т.п. Там не шелшок, но тоже я думаю пойдёт.

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

То что они ССЗБ было очевидно ещё до проблем с безопасностью, пусть теперь занимаются бекпортированием новых версий этой какашки. А вот пользователей этого жалко.

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

в сусе ковыряли что бекпортировать

Я думал, этим только в Debian занимаются.

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

Будет эпичней, если о root-уязвимости разработчики знали, но не отразили это в changelog...

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

SUSE Linux Enterprise 12 SP2

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

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

Будет эпичней, если о root-уязвимости разработчики знали, но не отразили это в changelog...

И что было бы? Уберфюрер всё время так делает, и ничего - https://lwn.net/Articles/704231/, как с рук сходило, так и будет. А тут сразу развонялись, типо вы скрываете!!!11

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

По первой ссылке багфиксы и только. Вторая - да, дыра. Хорошо что у меня openrc везде.

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

Ну, погугли уж аналогично openrc сам, авось не маленький ^_~

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

Ну, погугли уж аналогично openrc сам, авось не маленький ^_~

Погуглил перед тем как писать. Что-то нету нифига. Алсо, всего одна дыра за 10 лет - это не так страшно. В systemd их намного больше было. Один только ассерт на строки из внешней переменной чего стоит.

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

Один только ассерт на строки из внешней переменной чего стоит.

А что там было?

devzero ()

В примечании к исправлению указано, что исправленная ошибка может привести к DoS-атаке через исчерпание дискового пространства

Риторический вопрос: ну и как после этого можно говорить хоть о каком-то доверии к рыжей рукожопой мразине?

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

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

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

Это оправдание двойному стандарту или зачем мне это предложение?

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

А вот пользователей этого жалко.

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

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

Ляпота! Восхищен.

«Это вам не bash», говорили они. «Код простой, очевидный и легко поддаётся отладке», говорили они.

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

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

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

Ладно, Линусу можно, твоя нехитрая идея понятна.

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

Ну так и почему ты не указал на эту опасность?

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

«Это вам не bash», говорили они. «Код простой, очевидный и легко поддаётся отладке», говорили они.

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

Я так до конца и не понял, зачем было всё это совать в PID 1 и какой от этого профит, теряющийся при разделении systemd на отдельные компоненты. Или почему нельзя вообще вынести этот жирный блоб из PID 1 хотя бы, чтобы вся система не вставала колом очередной ошибке systemd.

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

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

Ну так вперёд тогда, тоже киллера для него нанимать. Потому что он клал на это с высокой колокольни, когда dirtyc0w закрывал.

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

Проблема systemd не в том, что он написан на C. Проблема в том, что весь этот жирный блоб висит в PID 1, работает с правами рута и выполняет чудовищное количество функций, для которых права рута не нужны.

Это всё вместе — единая огромная проблема. Он работает как PID1. Он содержит чудовищное количество логики, которое в PID1 абсолютно избыточно. Он написан на си. И его пишут люди, которые не имеют никакого представления, как писать на си защищенный код. (Да и на любом другом языке, впрочем.)

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

Почему «адекватные люди» не могут договориться с «адекватными людьми» из других таких же дистрибутивов и с разработчиками апстрима о создании LTS-ветки, которую они потом все вместе будут поддерживать? Или такое уже было, но разработчики systemd не одобрили?

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

Я указал местному сообществу на опасность использования не релизных версий systemd даже в «ынтерпрайных» дистрибутивах. С меня достаточно.

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

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

Это вообще забавная вещь. В старом примитивном ините арча можно было указать, какие демоны запускать асинхронно, а какие последовательно. Соответственно, всё необходимое запускалось последовательно, а остальное - затем асинхронно.

Когда впилили systemd, система стала грузиться медленнее раза в 3 или 4. Потому что он стартует максимум возможного асинхронно и упирается в пропускную способность дисковой подсистемы. Помню, как на ЛОРе пели дифирамбы с чудесной скоростной загрузки systemd, а я ржал с этих наркоманов...

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

https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet

Consider systemd's DNS resolver. DNS is a complicated, security-sensitive protocol. In August 2014, Lennart Poettering declared that «systemd-resolved is now a pretty complete caching DNS and LLMNR stub resolver.» In reality, systemd-resolved failed to implement any of the documented best practices to protect against DNS cache poisoning. It was vulnerable to Dan Kaminsky's cache poisoning attack which was fixed in every other DNS server during a massive coordinated response in 2008 (and which had been fixed in djbdns in 1999).

Аж слов нет.

Эх, собрались бы люди, подобные D.J.B, Laurent Bercot, Rich Felker, и создали бы высококачественный системный юзерленд для Linux... Мечты, мечты.

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

Или такое уже было, но разработчики systemd не одобрили?

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

Есть https://cgit.freedesktop.org/systemd/systemd-stable/ но там какая то замшелость.

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