The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Уязвимость в systemd, которую можно использовать для блокиро..., opennews (??), 19-Фев-19, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


1. "Уязвимость в systemd, которую можно использовать для блокиро..."  +46 +/
Сообщение от Аноним (1), 19-Фев-19, 10:21 
> В systemd устанавливается обработчик сигналов,
> пытающийся перехватить крахи процесса PID1...
> ядро не может вызвать данный обработчик сигнала
> и просто завершает процесс с PID 1

Очевидно, для решения проблемы потребуется systemd-kerneld.

Ответить | Правка | Наверх | Cообщить модератору

48. "Уязвимость в systemd, которую можно использовать для блокиро..."  +18 +/
Сообщение от zzz (??), 19-Фев-19, 11:54 
А кто тогда будет отрабатывать сегфолты в systemd-kerneld? Не подумали? А ведь это тоже вектор атаки.

Для защиты systemd-kerneld от подобного необходимо устанавливать систему в гипервизор systemd-hvd. А для купирования проблемы возможного сегфолта systemd-hvd, прикрутим ему аппаратный systemd-monitd.

В итоге мы получим вполне рабочую систему - за systemd присматривает systemd-kerneld, за которым присматривает гипервизор systemd-hvd, за которым присматривает systemd-monitd. Вот это уже похоже на нормальную систему инициализации, не то, что эти сисвишные портянки.

Ответить | Правка | Наверх | Cообщить модератору

68. "Уязвимость в systemd, которую можно использовать для блокиро..."  +4 +/
Сообщение от Michael Shigorinemail (ok), 19-Фев-19, 12:35 
> А кто тогда будет отрабатывать сегфолты в systemd-kerneld?

NOTABUG!

Ответить | Правка | Наверх | Cообщить модератору

190. "Уязвимость в systemd, которую можно использовать для блокиро..."  +/
Сообщение от Аноним (1), 20-Фев-19, 06:39 
assert спасёт гиганта мысли

+/* Note that the D-Bus specification states that bus paths shall have no size limit. We enforce here one
+ * anyway, since truly unbounded strings are a security problem. The limit we pick is relatively large however,
+ * to not clash unnecessarily with real-life applications. */
+#define BUS_PATH_SIZE_MAX (64*1024)

         /* Second, add fallback vtables registered for any of the prefixes */
-        prefix = alloca(strlen(path) + 1);
+        pl = strlen(path);
+        assert(pl <= BUS_PATH_SIZE_MAX);
+        prefix = new(char, pl + 1);
+        if (!prefix)
+                return -ENOMEM

https://github.com/systemd/systemd/commit/798ebaf9aea9b8ae3b...

Ответить | Правка | Наверх | Cообщить модератору

153. "Уязвимость в systemd, которую можно использовать для блокиро..."  +/
Сообщение от Аноним (1), 19-Фев-19, 16:33 
> А кто тогда будет отрабатывать сегфолты в systemd-kerneld?

В ядре нет сегфолтов. Там ловушки и прерывания. В данном случае double fault (это отдельный тип - abort, невосстанавливаемая ошибка). При этом юзерланд "сделал всё что мог". Появился повод говорить об ошибке дизайна в ядре. Так что в исходном сообщении не то что бы шутка. Как и в предложении запилить systemd-hvd.

Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

165. "Уязвимость в systemd, которую можно использовать для блокиро..."  –2 +/
Сообщение от Пользователь (?), 19-Фев-19, 18:24 
> за systemd присматривает systemd-kerneld, за которым присматривает гипервизор systemd-hvd, за которым присматривает systemd-monitd

Во всей этой лабуде уязвимостей не может быть в принципе?
> это уже похоже на нормальную систему инициализации

Сломал одно, а остальное посыпется уже само по себе.

Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

175. "Уязвимость в systemd, которую можно использовать для блокиро..."  +5 +/
Сообщение от xm (ok), 19-Фев-19, 23:17 
Ну то есть смерть PID 1 настолько нормальная ситуация с systemd что они даже обработчик штатный написали. Надёжность!
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

189. "Уязвимость в systemd, которую можно использовать для блокиро..."  –1 +/
Сообщение от Аноним (1), 20-Фев-19, 06:36 
Отправка сигнала извне это штатная ситуация или нет? Надо ли её предусмотреть и обработать?

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру