LINUX.ORG.RU

systemd local DoS

 


1

5

В системном менеджере systemd выявлена локальная уязвимость. Процесс PID 1 зависает на системном вызове pause() при поступлении в сокет уведомлений systemd сообщения нулевой длины, после чего невозможно запустить/остановить демоны или выполнить «чистую» перезагрузку, а systemd-сервисы в стиле inetd перестают принимать соединения. Так как сокет уведомлений /run/systemd/notify доступен всем на запись, то любые локальные пользователи могут вызвать отказ в обслуживании на системах с systemd.

Уязвимость проявляется во всех версиях systemd, начиная, по крайней мере, с версии 209.

Атака сводится к выполнению команды

NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""

>>> Подробности

★★★★★

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

А причем тут PID 1 вообще? Речь идет о systemd в целом.

добавилась ещё сложность точек сопряжения?

И какая точка сопряжения добавится между демоном синхронизации времени и демоном инициализации?

кому потребуется выкидывать что-то из функциональности systemd

Скорее всего никому, потому что systemd проще не устанавливать. Как я, собственно, на hardened серверах и делаю.

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

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

И какая точка сопряжения добавится

Никакой, потому что это две независимые программы (полностью).

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

Скорее всего никому, потому что systemd проще не устанавливать. Как я, собственно, на hardened серверах и делаю.

Как ты ухитряешься не устанавливать systemd в RHEL 7?

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

потому что всё остальное работает без рута

И это автоматически решает все проблемы безопасности? Так считать очень наивно.

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

Как ты ухитряешься не устанавливать systemd в RHEL 7?

Очень просто — там, где очень важна безопасность, использую Gentoo.

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

всё остальное работает без рута

мне кажется это не совсем верно

ps aux | grep systemd | grep root
root       261  0.0  0.1  77644 37644 ?        Ss   сен08   0:10 /usr/lib/systemd/systemd-journald
root       295  0.0  0.0  36088  3720 ?        Ss   сен08   0:02 /usr/lib/systemd/systemd-udevd
root       501  0.0  0.0  38516  3764 ?        Ss   сен08   0:02 /usr/lib/systemd/systemd-logind
systemctl --version
systemd 231
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN

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

Security by obscurity?

Нет. А почему ты так решил?

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

Твоя правда. Есть бинарники, которые работают от рута. Но они не перестают быть опциональными.

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

Не договаривай за меня. Ты протестовал против отсутствия модульности в systemd, которое якобы заставляет тебя выполнять в своей системе ненужный код и таким образом увеличивать поверхность атаки. Я ответил, что это не так, поскольку почти (кроме udev) все компоненты systemd (по границам бинарников) отключаемы и взаимозаменяемы, а дробить на модули дальше (например, разбивать PID 1 на куски) нецелесообразно.

Слова про «не от рута» — не более чем примечание на полях (к тому же ещё и не совсем верное, см. выше).

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

Никакой, потому что это две независимые программы (полностью).

Тогда почему они вообще находятся в одном дереве исходников? Это же не ls и cat.

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

почти (кроме udev) все компоненты systemd (по границам бинарников) отключаемы и взаимозаменяемы

ШТО. udev вроде никто раньше не заставлял использовать. Это journald нельзя убрать совсем, не?

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

Тогда почему они вообще находятся в одном дереве исходников?

А почему stty, chown и tr находятся в одном дереве?

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

А почему stty, chown и tr находятся в одном дереве?

И ведь действительно, в чем причина того, что столь разнородные утилиты находятся в одном дереве?

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

Тогда почему они вообще находятся в одном дереве исходников?

Because we can.

With some greetings, Lennart Pottering.

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

journald убрать можно (замаскировать сервис и сокет), хоть и говорят, что нельзя. Просто потеряешь все логи. А между systemd и udev сейчас внутренний интерфейс (не libudev), и я не уверен, что systemd перенесёт отсутствие udev.

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