1.3, КО (?), 10:12, 22/08/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
"при наличии доступа к пользователю"
Нравятся мне все эти уязвимости, надо сначала узнать где атакуемый, что да как у человека установлено, только потом уже можно вершить свои дела...
| |
|
2.6, Michael Shigorin (ok), 11:09, 22/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
Да, тут непонятно сходу, какая польза может быть. Если проломили уже запущенный chrony и так получили исполнение с его правами -- pid-файлик уже существует. Если получили переключением привилегий -- можно было их не переключать и воротить вообще всё что заблагорассудится.
Но в любом случае это уязвимость не собственно данного сервиса, а самой схемы с принадлежащими псевдопользователям /run/*/.
| |
|
3.17, Алексей (??), 18:50, 22/08/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
> это уязвимость не собственно данного сервиса, а самой схемы с принадлежащими псевдопользователям /run/*/.
Если бы /run/chrony таки принадлежал пользователю chrony, то pid файл не нужно было бы создавать от root, и никакой уязвимости не было бы:
> Уязвимость вызвана небезопасным созданием pid-файла, который создавался на этапе, когда chrony ещё не сбросил привилегии и выполняется с правами root.
А так-то это уязвимость не chrony, а допотопных init'ов, которым нужны эти самые pid файлы.
| |
|
4.21, Аноним (21), 20:48, 22/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Если бы /run/chrony таки принадлежал пользователю chrony, то pid файл не нужно было бы создавать от root, и никакой уязвимости не было бы:
Он и принадлежит chrony. Там должен находиться сокет для работы с chronyc. Просто в Fedora/RHEL зачем-то решили в него запихнуть pid-файл, который создается от рута by design (это поведение и называют "уязвимостью"). В Debian, Ubuntu и SUSE pid-файл лежит непосредственно в /run, и "уязвимость" эксплуатировать невозможно.
| |
|
5.32, Алексей (??), 17:34, 24/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
> в Fedora/RHEL зачем-то решили в него запихнуть pid-файл, который создается от рута by design
Вот это самое "создается от рута by design" и есть уязвимость.
И необходимость записывать в файл pid - это еще одна уязвимость.
| |
|
|
3.25, Аноним (25), 13:47, 23/08/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
А что, переключение привилегий только из под рута только возможно?
| |
|
|
1.4, Ilya Indigo (ok), 10:18, 22/08/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> SUSE и openSUSE проблеме не подвержены.
Уже во второй новости про уязвимости это читаю.
Совпадение?
| |
|
|
3.10, Ilya Indigo (ok), 11:15, 22/08/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Кто то из SUSE имеет отношение к этим уязвимостям? :D
Имеет отношение к их отсутствию в них.
| |
|
2.22, Аноним (21), 20:52, 22/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> SUSE и openSUSE проблеме не подвержены.
> Уже во второй новости про уязвимости это читаю.
> Совпадение?
Дебиан с убунтой тоже, просто про это никто не пишет.
| |
|
1.9, Аноним (9), 11:14, 22/08/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
>>через systemd-tmpfiles
О сколько нам открытий новых подарит это сустемД.
На самом деле эта система символических ссылок уже не раз порождала подобные дыры. Архитектурная дырень я бы сказал.
| |
1.11, Аноним (11), 11:44, 22/08/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Нужно systemd-timesyncd использовать. Не зря же его основатель systemd делал. Почему его в 8 редхате не используют?
| |
1.14, Аноним (14), 13:35, 22/08/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Перед созданием pid-файла не проверяется что файл существует и он не обычный, а symlink, dev, pipe и что там ещё может быть?
Ну вот что экономят? Скорей, скорей запуститься?
Это прям какая-то systemd-болезнь - "запуск за 3 секунды".
| |
|
2.15, Michael Shigorin (ok), 13:55, 22/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Перед созданием pid-файла не проверяется что файл существует
Хозяйке на заметку: даже если проверить, всё ещё возможна гонка класса TOCTOU.
| |
|
3.23, Аноним (14), 23:34, 22/08/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
O_CREAT | O_EXCL - perror("Я уже запущен см. мой pid-файл").
| |
|
2.28, Аноним (27), 13:18, 24/08/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
запуск заглушек за 3 сек, а потом 30 сек ждать, пока реально всё заработает.
| |
|
1.18, Аноним (18), 19:40, 22/08/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Ниче не понял. Зачем вообще нужны pid файлы когда есть процесс-babysitter systemd или как до него - upstart? Это проблемы скорее относятся к архаичной sysvinit. Ящитаю новость высосана из пальца, автор - самизнаетекто.
| |
|
2.24, Аноним (24), 13:31, 23/08/2020 [^] [^^] [^^^] [ответить]
| +/– |
Искоробочный юнит крони тоже рассчитан на то, что он сам демонизируется и запишет пид в файл. Удивляюсь, почему, если в любой запускалке сервисов есть супервайзеры, которые следят за запущенными процессами.
| |
|
3.34, Алексей (??), 17:45, 24/08/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Удивляюсь, почему, если в любой запускалке сервисов есть супервайзеры
Потому, что отучивать каждого чудака от double fork - себе дороже. Проще в ядре запилить костыли (cgroups), которые сохраняют то состояние, от которого пытается избавиться double fork
| |
|
2.30, Michael Shigorin (ok), 14:12, 24/08/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
> процесс-babysitter systemd
А, так когда он скрины прибивает -- это потому, что процесс -- babyshitter, так и запишем.
| |
|
1.19, Аноним (21), 20:38, 22/08/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> В процессе подготовки обновления для RHEL, Debian и Ubuntu. SUSE и openSUSE проблеме не подвержены, так как символическая ссылка для chrony создаётся непосредственно в каталоге /run, без применения дополнительных подкаталогов.
В Debian и Ubuntu pid-файл chrony.pid также создается в каталоге /run.
В /run/chrony только chronyd.sock, который создается от пользователя chrony.
| |
1.37, Аноним (37), 17:09, 27/08/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
в убунту 20.04 выкинули ее в пользу
systemd-timesyncd/focal-updates,now 245.4-4ubuntu3.2 amd64 [установлен, автоматически]
minimalistic service to synchronize local time with NTP servers
| |
|