Як вбити systemd однією командою

За допомогою наступної команди ви можете повністю обрушити systemd і неважливо від імені якого користувача ви її виконаєте:

Як все працює показано на відео:

Як вбити Systemd за допомогою однієї команди

Цей баг дуже банальна. Команда systemd-notify відправляє повідомлення нульової довжини на доступний всім сокет UNIX, який розташований за адресою / run / systemd / notify. Процес з PID 1 отримує це повідомлення і падає, тому що розмір повідомлення не більше нуля. Але незважаючи на банальність, це дуже серйозна помилка, тому що вона дозволяє будь-якому локальному користувачеві дуже просто вивести з ладу один з найважливіших компонентів системи.

У зв`язку з цією помилкою відразу виникає питання, чи дійсно допустимо, щоб найпопулярніша система ініціалізації з такою простою помилкою існувала більше двох років? Помилка відтворюється починаючи з Systemd 209. Хіба порожній рядок це не очевидний тест?

Батьківський процес PID 1, це найважливіший процес в просторі користувача і до його якості можна було б відноситься краще. Не обов`язково ж було завершувати процес, можна було просто вивести повідомлення в журнал.

Проблеми Systemd лежать глибше цієї помилки. Systemd неправильна за своєю суттю. Написання стабільних програм дуже складно. І навіть професійні програмісти неминуче припускаються помилок в проектах такого масштабу і складності. Але вони розуміють всі складнощі і зводять до мінімуму ймовірність помилок або хоча б намагаються мінімізувати їх дію. Розробники Systemd, схоже не розуміють всього цього і намагаються запхати в батьківський процес PID 1 багато непотрібних і дуже складних речей, що дуже небезпечно.

Деяка складність обов`язкове, оскільки Systemd надає дуже багато важливих і корисних функцій. Неважливо хто це зробив би, Systemd або хтось інший, але потрібно знайти компроміс між складністю і функціональністю.

Ми не говоримо про складності всього Systemd, нас цікавить тільки PID 1. Єдине завдання, яку він повинен виконувати - це ініціалізувати систему ініціалізації і вбивати зомбі процеси. Все інше ж має бути побудовано за модульним принципом, щоб збій в одному з модулів не руйнував всю систему. Наприклад, збій в коді управління сервісами не повинен ніяк впливати на нормальну перезавантаження.

Будь-код, який приймає повідомлення від недовірених джерел, повинен працювати в окремому непривілейованому процесі, такому як systemd-notify. Цей процес повинен перевірити повідомлення, перед тим як передати його привілейованого. Це називається поділ привілеїв і є найкращою практикою в інформаційній безпеці.

Systemd ж навпаки, робить аналіз повідомлення від ненадійних джерел на Сі в процесі з PID 1. Якщо ви думаєте, що Systemd не потрібно поділ привілеїв, тому що повідомлення виходять тільки від локальних користувачів, то зауважте, що зараз і локальні атаки можуть бути виконані через інтернет.

Але давайте підемо ще далі. Systemd має проблеми з безпекою і в інших місцях. Наприклад, в тому ж процесі PID 1 функція umask встановлює повноваження в 0. Це означає, що всі файли, створені systemd, будуть доступні для читання і запису за замовчуванням. Потім, якщо потрібно Systemd змінює ці повноваження на більш суворі. Але в ідеалі все повинно бути навпаки, спочатку заборонити всі, а потім вже вирішити то що потрібно. У такому випадку, якщо забути поміняти права для такого файлу, то він просто не буде працювати.

Якщо ж systemd забуде поміняти права, що траплялося вже два рази, то файл буде працювати, тільки залишить дірку в безпеці системи, оскільки до нього зможуть отримати доступ усі бажаючі.

Спочатку операційна система Linux вважалася еталоном безпеки і надійного програмного забезпечення. У той час як Microsoft покращувала свою Windows, а Apple MacOS, розробники вільного ПЗ, схоже, розслабилися. Але є зрушення в позитивну сторону виявлення Heartbleed і Shellshock були тим тривожним дзвіночком, який змусив розробників уважніше ставитися до якості програмного забезпечення.

Були розроблені нові, безпечні мови для системного програмування, такі як Go і Rust. Systemd була написана на Сі, і вона небезпечна хоча б тому, що містить сотні тисяч рядків складного коду на Сі без використання багаторічних практик безпеки, таких як поділ привілеїв і відмовостійкий дизайн. Але тим не менше ставить перед собою завдання бути незамінною.

Systemd - це вже більше ніж система ініціалізації. Це ядро ​​вторинної операційної системи. Вона забезпечує журнал, менеджер пристроїв, управління контейнерами, входом в систему, клієнт DHCP, DNS, клієнт NTP. Система створює інтерфейси, які можуть використовувати інші додатки, а це робить її незамінною.

Systemd використовується в більшості дистрибутивів Linux. Система ініціалізації була легкою мішенню для Systemd, тому що існуючі системи ініціалізації були настільки погані, що не могли скласти конкуренцію. Але це не зовсім вірно для інших сервісів, які намагається замінити Systemd, управління мережею, DNS, NTP.

Systemd перелагает дуже мало функцій, в порівнянні з існуючими рішеннями і несе в собі певний ризик. Можливо, не варто так прагнути використовувати Systemd всюди, щоб в майбутньому можна було впровадити більш безпечні альтернативи, коли вони з`являться. Але це буде можливо, тільки якщо Systemd не зруйнує всю модульність системи і стандарти.