В chrony, реализации протокола NTP, применяемой для синхронизации точного времени в большинстве дистрибутивов Linux, выявлена уязвимость (CVE-2020-14367), позволяющая перезаписать любой файл в системе, имея доступ к локальному непривилегированному пользователю chrony. Уязвимость может быть эксплуатирована только через пользователя chrony, что снижает её опасность. Тем не менее, проблема компрометирует уровень изоляции в chrony и может использоваться в случае выявление другой уязвимости в коде, выполняемом после сброса привилегий...Подробнее: https://www.opennet.me/opennews/art.shtml?num=53580
В Debian не используется по-умолчанию chrony.
"при наличии доступа к пользователю"
Нравятся мне все эти уязвимости, надо сначала узнать где атакуемый, что да как у человека установлено, только потом уже можно вершить свои дела...
Да, тут непонятно сходу, какая польза может быть. Если проломили уже запущенный chrony и так получили исполнение с его правами -- pid-файлик уже существует. Если получили переключением привилегий -- можно было их не переключать и воротить вообще всё что заблагорассудится.Но в любом случае это уязвимость не собственно данного сервиса, а самой схемы с принадлежащими псевдопользователям /run/*/.
Почему псевдо? Даже нобади не псевдо.
> это уязвимость не собственно данного сервиса, а самой схемы с принадлежащими псевдопользователям /run/*/.Если бы /run/chrony таки принадлежал пользователю chrony, то pid файл не нужно было бы создавать от root, и никакой уязвимости не было бы:
> Уязвимость вызвана небезопасным созданием pid-файла, который создавался на этапе, когда chrony ещё не сбросил привилегии и выполняется с правами root.
А так-то это уязвимость не chrony, а допотопных init'ов, которым нужны эти самые pid файлы.
> Если бы /run/chrony таки принадлежал пользователю chrony, то pid файл не нужно было бы создавать от root, и никакой уязвимости не было бы:Он и принадлежит chrony. Там должен находиться сокет для работы с chronyc. Просто в Fedora/RHEL зачем-то решили в него запихнуть pid-файл, который создается от рута by design (это поведение и называют "уязвимостью"). В Debian, Ubuntu и SUSE pid-файл лежит непосредственно в /run, и "уязвимость" эксплуатировать невозможно.
> в Fedora/RHEL зачем-то решили в него запихнуть pid-файл, который создается от рута by designВот это самое "создается от рута by design" и есть уязвимость.
И необходимость записывать в файл pid - это еще одна уязвимость.
А что, переключение привилегий только из под рута только возможно?
> SUSE и openSUSE проблеме не подвержены.Уже во второй новости про уязвимости это читаю.
Совпадение?
Кто то из SUSE имеет отношение к этим уязвимостям? :D
> Кто то из SUSE имеет отношение к этим уязвимостям? :DИмеет отношение к их отсутствию в них.
>> SUSE и openSUSE проблеме не подвержены.
> Уже во второй новости про уязвимости это читаю.
> Совпадение?Дебиан с убунтой тоже, просто про это никто не пишет.
Ох ты ж блджад, надо будет обновиться, хотя риск эксплуатации и 0.
И опять SUSE выруливают.
:Р
>>через systemd-tmpfilesО сколько нам открытий новых подарит это сустемД.
На самом деле эта система символических ссылок уже не раз порождала подобные дыры. Архитектурная дырень я бы сказал.
Проще описать, какие службы системды БЕЗ дыр. Ответ: никакие.
Нужно systemd-timesyncd использовать. Не зря же его основатель systemd делал. Почему его в 8 редхате не используют?
есть дистрибутивы без systemd
В них безопасность — не главное.
У меня в ubuntu не установлен по умолчанию.
Перед созданием pid-файла не проверяется что файл существует и он не обычный, а symlink, dev, pipe и что там ещё может быть?Ну вот что экономят? Скорей, скорей запуститься?
Это прям какая-то systemd-болезнь - "запуск за 3 секунды".
> Перед созданием pid-файла не проверяется что файл существуетХозяйке на заметку: даже если проверить, всё ещё возможна гонка класса TOCTOU.
O_CREAT | O_EXCL - perror("Я уже запущен см. мой pid-файл").
запуск заглушек за 3 сек, а потом 30 сек ждать, пока реально всё заработает.
Ниче не понял. Зачем вообще нужны pid файлы когда есть процесс-babysitter systemd или как до него - upstart? Это проблемы скорее относятся к архаичной sysvinit. Ящитаю новость высосана из пальца, автор - самизнаетекто.
Искоробочный юнит крони тоже рассчитан на то, что он сам демонизируется и запишет пид в файл. Удивляюсь, почему, если в любой запускалке сервисов есть супервайзеры, которые следят за запущенными процессами.
> Удивляюсь, почему, если в любой запускалке сервисов есть супервайзерыПотому, что отучивать каждого чудака от double fork - себе дороже. Проще в ядре запилить костыли (cgroups), которые сохраняют то состояние, от которого пытается избавиться double fork
Зачем его сохранять?..
> процесс-babysitter systemdА, так когда он скрины прибивает -- это потому, что процесс -- babyshitter, так и запишем.
> или как до него - upstart?А до него runit, а до него daemontools (http://cr.yp.to/daemontools.html), а до него...
Но, блин, люди все равно "поджигают дом и сводят задачу к предыдущей".
> В процессе подготовки обновления для RHEL, Debian и Ubuntu. SUSE и openSUSE проблеме не подвержены, так как символическая ссылка для chrony создаётся непосредственно в каталоге /run, без применения дополнительных подкаталогов.В Debian и Ubuntu pid-файл chrony.pid также создается в каталоге /run.
В /run/chrony только chronyd.sock, который создается от пользователя chrony.
ntp - дыра и прошлый век
до системды такой фигни не было.
Что нужно? Протокол на базе http-xml.
в убунту 20.04 выкинули ее в пользу
systemd-timesyncd/focal-updates,now 245.4-4ubuntu3.2 amd64 [установлен, автоматически]
minimalistic service to synchronize local time with NTP servers