В systemd обнаружена уязвимость, которая уже описана в (CVE-2019-6454), какие позволяет вызвать блокировку процесса инициализации управления (PID1) при отправке специально созданного сообщения непривилегированному пользователю по D-Bus.
Разработчики Red Hat также не исключают возможность использования уязвимости для организации выполнения кода с правами root., но окончательная возможность такой атаки пока не определена.
О systemd
Для тех, кто не знает Systemd Я могу сказать тебе это это система инициализации linux и менеджер служб который включает в себя такие функции, как запуск демона по требованию, автоматическое монтирование и обслуживание точек монтирования, поддержку моментальных снимков и отслеживание процессов с использованием групп управления Linux.
Systemd предоставляет демон реестра и другие инструменты и утилиты, помогающие с общими задачами системного администрирования. Леннарт Поеттеринг и Кей Сиверс написали SystemD, вдохновленные macOS launchd и Upstart, с целью создания современной и динамичной системы.
В частности, systemd предоставляет возможности агрессивного распараллеливания и логику управления службами на основе зависимостей, позволяя службам запускаться параллельно и сокращая время запуска. Эти два аспекта присутствовали в Upstart, но были улучшены с помощью systemd.
Systemd - это система загрузки по умолчанию для основных дистрибутивов Linux., но он обратно совместим со сценариями запуска SysV.
SysVinit - это система инициализации, которая предшествует systemd и использует упрощенный подход для запуска службы. Systemd не только управляет инициализацией системы, но также предоставляет альтернативы другим хорошо известным утилитам, таким как cron и syslog.
О новой уязвимости systemd
Изменяя размер сообщения, отправляемого через D-Bus, злоумышленник может переместить указатель за пределы памяти, выделенной для стека, обходя защиту «stack guard-page», которая основана на подстановке страницы памяти на краю, вызывающей исключение (отказ страницы).
Успешная атака продемонстрирована на Ubuntu 18.10 с systemd 239 и на CentOS 7.6 с systemd 219.
В качестве обходного пути можно использовать компиляцию в GCC с параметром «-fstack-clash-protection», который используется по умолчанию в Fedora 28 и 29.
Следует отметить, что в 2014 году автор системной библиотеки MUSL среди основных архитектурных проблем указал на systemd чрезмерную инфляцию обработчика PID1 и поставил под сомнение возможность реализации API контроллера уровня PID1 для связи с шиной, поскольку это серьезный вектор для атаки и могут отрицательно повлиять на надежность всей системы
По словам исследователя безопасности, который выявлена уязвимость, изменение указателя стека возможно только для неиспользуемых страниц памяти (unassigned), что не позволяет организовать выполнение кода в контексте процесса PID1, но позволяет злоумышленнику инициировать блокировку PID1 с последующим переходом ядра Linux в состояние «паника» (в случае Неисправность ПИД-регулятора 1, зависает вся система).
В systemd установлен обработчик сигналов, который пытается перехватить сбои процесса PID1 (ошибка сегментации) и запускает оболочку для восстановления.
Но поскольку во время атаки выполняется вызов недублированных (нераспределенных) страниц памяти, ядро не может вызвать этот обработчик сигнала и просто завершает процесс с PID 1, что, в свою очередь, делает невозможным продолжить работу и перейти к состояние «паника», поэтому требуется перезагрузка системы.
Решение проблемы уже есть
Как и любая проблема безопасности, уже описанная и сообщенная, ее публикация не может быть произведена до тех пор, пока проблема не будет решена и Обновления исправлений уязвимостей для SUSE / openSUSE, Fedora уже выпущены, также для Ubuntu и частично для Debian (Только для Debian Stretch).
Хотя в RHEL проблема остается неисправленной.
Дело в том, что у systemd есть все признаки того, чтобы стать огромным троянским конем. Это противоречит философии UNIX «Делай одно и делай это хорошо», и нам придется за это платить.
Я думаю так же…
Лично я довольно консервативен в отношении системы запуска, я думаю, как самые старые и самые традиционные пользователи традиционной и примитивной UNIX: Я ПРЕДПОЧИТАЮ СИСТЕМУ V INIT ИЛИ БЫТЬ ТРАДИЦИОННЫМ SYSVINIT НАВСЕГДА. SYSTEMD (Я УСТАНОВИЛ В LIMUX DEBIAN 8.3, ОСТАВшемся в THINKPAD T450, который я украл в марте 2017 года) SYSTEMD НИКОГДА НЕ УБЕДИЛИ МЕНЯ
systemd отстой !!