The OpenNET Project / Index page

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



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

"Уязвимость в chrony"  +/
Сообщение от opennews (ok), 22-Авг-20, 09:51 
В chrony, реализации протокола NTP, применяемой для синхронизации точного времени в большинстве дистрибутивов Linux, выявлена уязвимость (CVE-2020-14367), позволяющая  перезаписать любой файл в системе, имея доступ к локальному непривилегированному пользователю chrony. Уязвимость может быть эксплуатирована только через пользователя chrony, что снижает её опасность. Тем не менее, проблема компрометирует уровень изоляции в chrony и может использоваться в случае выявление другой уязвимости в коде, выполняемом после сброса привилегий...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53580

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

Оглавление

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

2. Сообщение от timur.davletshinemail (ok), 22-Авг-20, 09:52   –2 +/
В Debian не используется по-умолчанию chrony.
Ответить | Правка | Наверх | Cообщить модератору

3. Сообщение от КО (?), 22-Авг-20, 10:12   +/
"при наличии доступа к пользователю"
Нравятся мне все эти уязвимости, надо сначала узнать где атакуемый, что да как у человека установлено, только потом уже можно вершить свои дела...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6

4. Сообщение от Ilya Indigo (ok), 22-Авг-20, 10:18   +/
> SUSE и openSUSE проблеме не подвержены.

Уже во второй новости про уязвимости это читаю.
Совпадение?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #22

5. Сообщение от Онаним (?), 22-Авг-20, 10:34   +/
Ох ты ж блджад, надо будет обновиться, хотя риск эксплуатации и 0.
Ответить | Правка | Наверх | Cообщить модератору

6. Сообщение от Michael Shigorinemail (ok), 22-Авг-20, 11:09   +/
Да, тут непонятно сходу, какая польза может быть.  Если проломили уже запущенный chrony и так получили исполнение с его правами -- pid-файлик уже существует.  Если получили переключением привилегий -- можно было их не переключать и воротить вообще всё что заблагорассудится.

Но в любом случае это уязвимость не собственно данного сервиса, а самой схемы с принадлежащими псевдопользователям /run/*/.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #16, #17, #25

7. Сообщение от VINRARUS (ok), 22-Авг-20, 11:11   +/
И опять  SUSE выруливают.

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

8. Сообщение от VINRARUS (ok), 22-Авг-20, 11:13   +2 +/
Кто то из SUSE имеет отношение к этим уязвимостям? :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #10

9. Сообщение от Аноним (9), 22-Авг-20, 11:14   –2 +/
>>через systemd-tmpfiles

О сколько нам открытий новых подарит это сустемД.

На самом деле эта система символических ссылок уже не раз порождала подобные дыры. Архитектурная дырень я бы сказал.

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

10. Сообщение от Ilya Indigo (ok), 22-Авг-20, 11:15   –1 +/
> Кто то из SUSE имеет отношение к этим уязвимостям? :D

Имеет отношение к их отсутствию в них.

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

11. Сообщение от Аноним (11), 22-Авг-20, 11:44   –2 +/
Нужно systemd-timesyncd использовать. Не зря же его основатель systemd делал. Почему его в 8 редхате не используют?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13

12. Сообщение от Аноним (12), 22-Авг-20, 12:26   +/
У меня в ubuntu не установлен по умолчанию.
Ответить | Правка | Наверх | Cообщить модератору

13. Сообщение от anonymous (??), 22-Авг-20, 12:45   –2 +/
есть дистрибутивы без systemd
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #20

14. Сообщение от Аноним (14), 22-Авг-20, 13:35   –1 +/
Перед созданием pid-файла не проверяется что файл существует и он не обычный, а symlink, dev, pipe и что там ещё может быть?

Ну вот что экономят? Скорей, скорей запуститься?
Это прям какая-то systemd-болезнь - "запуск за 3 секунды".

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #28

15. Сообщение от Michael Shigorinemail (ok), 22-Авг-20, 13:55   +/
> Перед созданием pid-файла не проверяется что файл существует

Хозяйке на заметку: даже если проверить, всё ещё возможна гонка класса TOCTOU.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #23

16. Сообщение от Аноним (16), 22-Авг-20, 18:30   +2 +/
Почему псевдо? Даже нобади не псевдо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

17. Сообщение от Алексей (??), 22-Авг-20, 18:50   –2 +/
> это уязвимость не собственно данного сервиса, а самой схемы с принадлежащими псевдопользователям /run/*/.

Если бы /run/chrony таки принадлежал пользователю chrony, то pid файл не нужно было бы создавать от root, и никакой уязвимости не было бы:

> Уязвимость вызвана небезопасным созданием pid-файла, который создавался на этапе, когда chrony ещё не сбросил привилегии и выполняется с правами root.

А так-то это уязвимость не chrony, а допотопных init'ов, которым нужны эти самые pid файлы.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #21

18. Сообщение от Аноним (18), 22-Авг-20, 19:40   –1 +/
Ниче не понял. Зачем вообще нужны pid файлы когда есть процесс-babysitter systemd или как до него - upstart? Это проблемы скорее относятся к архаичной sysvinit. Ящитаю новость высосана из пальца, автор - самизнаетекто.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24, #30, #33

19. Сообщение от Аноним (21), 22-Авг-20, 20:38   +/
>  В процессе подготовки обновления для RHEL, Debian и Ubuntu. SUSE и openSUSE проблеме не подвержены, так как символическая ссылка для chrony создаётся непосредственно в каталоге /run, без применения дополнительных подкаталогов.

В Debian и Ubuntu pid-файл chrony.pid также создается в каталоге /run.
В /run/chrony только chronyd.sock, который создается от пользователя chrony.

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

20. Сообщение от Аноним (21), 22-Авг-20, 20:39   +3 +/
В них безопасность — не главное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

21. Сообщение от Аноним (21), 22-Авг-20, 20:48   +/
> Если бы /run/chrony таки принадлежал пользователю chrony, то pid файл не нужно было бы создавать от root, и никакой уязвимости не было бы:

Он и принадлежит chrony. Там должен находиться сокет для работы с chronyc. Просто в Fedora/RHEL зачем-то решили в него запихнуть pid-файл, который создается от рута by design (это поведение и называют "уязвимостью"). В Debian, Ubuntu и SUSE pid-файл лежит непосредственно в /run, и "уязвимость" эксплуатировать невозможно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #32

22. Сообщение от Аноним (21), 22-Авг-20, 20:52   +/
>> SUSE и openSUSE проблеме не подвержены.
> Уже во второй новости про уязвимости это читаю.
> Совпадение?

Дебиан с убунтой тоже, просто про это никто не пишет.

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

23. Сообщение от Аноним (14), 22-Авг-20, 23:34   +1 +/
O_CREAT | O_EXCL - perror("Я уже запущен см. мой pid-файл").
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

24. Сообщение от Аноним (24), 23-Авг-20, 13:31   +/
Искоробочный юнит крони тоже рассчитан на то, что он сам демонизируется и запишет пид в файл. Удивляюсь, почему, если в любой запускалке сервисов есть супервайзеры, которые следят за запущенными процессами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #34

25. Сообщение от Аноним (25), 23-Авг-20, 13:47   –1 +/
А что, переключение привилегий только из под рута только возможно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

26. Сообщение от Аноним (26), 23-Авг-20, 14:05   –3 +/
ntp - дыра и прошлый век
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29, #35

27. Сообщение от Аноним (27), 24-Авг-20, 13:15   +/
Проще описать, какие службы системды БЕЗ дыр. Ответ: никакие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

28. Сообщение от Аноним (27), 24-Авг-20, 13:18   +1 +/
запуск заглушек за 3 сек, а потом 30 сек ждать, пока реально всё заработает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

29. Сообщение от Аноним (27), 24-Авг-20, 13:19   +1 +/
до системды такой фигни не было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

30. Сообщение от Michael Shigorinemail (ok), 24-Авг-20, 14:12   –2 +/
> процесс-babysitter systemd

А, так когда он скрины прибивает -- это потому, что процесс -- babyshitter, так и запишем.

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

32. Сообщение от Алексей (??), 24-Авг-20, 17:34   +/
> в Fedora/RHEL зачем-то решили в него запихнуть pid-файл, который создается от рута by design

Вот это самое "создается от рута by design" и есть уязвимость.
И необходимость записывать в файл pid - это еще одна уязвимость.

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

33. Сообщение от Алексей (??), 24-Авг-20, 17:42   +/
> или как до него - upstart?

А до него runit, а до него daemontools (http://cr.yp.to/daemontools.html), а до него...

Но, блин, люди все равно "поджигают дом и сводят задачу к предыдущей".

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

34. Сообщение от Алексей (??), 24-Авг-20, 17:45   +1 +/
> Удивляюсь, почему, если в любой запускалке сервисов есть супервайзеры

Потому, что отучивать каждого чудака от double fork - себе дороже. Проще в ядре запилить костыли (cgroups), которые сохраняют то состояние, от которого пытается избавиться double fork

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #38

35. Сообщение от Kusb (?), 24-Авг-20, 19:43   +/
Что нужно? Протокол на базе http-xml.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

37. Сообщение от Аноним (37), 27-Авг-20, 17:09   +/
в убунту 20.04 выкинули ее в пользу
systemd-timesyncd/focal-updates,now 245.4-4ubuntu3.2 amd64 [установлен, автоматически]
  minimalistic service to synchronize local time with NTP servers
Ответить | Правка | Наверх | Cообщить модератору

38. Сообщение от nuclightemail (??), 23-Ноя-20, 02:00   +/
Зачем его сохранять?..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34


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

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




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

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