В системі systemd була виявлена уразливість, яка вже описана в (CVE-2019-6454), що дозволяє блокувати процес ініціалізації управління (PID1) під час надсилання спеціально створеного повідомлення непривілейованому користувачеві через D-Bus.
L Розробники 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, зловмисник може перемістити покажчик за межі пам'яті, виділеної для стека, минаючи захист "стека-захисної сторінки", який базується на підміні сторінки пам'яті на краю, що викликає виняток (помилка сторінки).
Успішна атака демонструється на Ubuntu 18.10 з systemd 239 та на CentOS 7.6 з systemd 219.
Як обхідний спосіб компіляцію можна використовувати в GCC із опцією "-fstack-clash-protection", яка використовується за замовчуванням у Fedora 28 та 29.
Слід зазначити, що у 2014 році автор системної бібліотеки MUSL серед основних архітектурних проблем виділив системну обробницю надмірної інфляції PID1 та поставив під сумнів доцільність впровадження API контролера рівня PID1 для Link with the Bus, оскільки це серйозний вектор для атак і може негативно позначитися на надійності всієї системи
На думку дослідника безпеки, який виявив уразливість, зміна покажчика стека можлива лише для невикористаних сторінок пам'яті (непризначений), який не дозволяє організувати виконання коду в контексті процесу PID1, але дозволяє зловмиснику ініціювати блокування PID1 з подальшим переходом ядра Linux у стан "паніки" (у випадку Помилка ПІД-контролера 1, вся система зависає).
У systemd встановлюється обробник сигналу, який намагається зафіксувати несправності процесу PID1 (помилка сегментації) і запускає оболонку для відновлення.
Але оскільки під час атаки здійснюється виклик на недубльовані (нерозподілені) сторінки пам’яті, ядро не може викликати цей обробник сигналу, а просто завершує процес за допомогою PID 1, що, в свою чергу, Неможливо продовжувати працювати і переходити в стан "паніки", тому необхідна перезавантаження системи.
Вирішення проблеми вже є
Як і будь-яка проблема безпеки, вже описана та повідомлена, її публікація не може бути здійснена, доки проблему не буде вирішено та оновлення виправлення вразливості для SUSE / openSUSE, Fedora вже випущено, також для Ubuntu і частково для Debian (Лише для Debian Stretch).
Хоча проблема залишається невиправленою у RHEL.