In Systemd wurde eine neue Sicherheitsanfälligkeit entdeckt

In systemd wurde eine Sicherheitslücke gefunden, die bereits in beschrieben ist (CVE-2019-6454), welche Ermöglicht das Blockieren des Steuerungsinitialisierungsprozesses (PID1) beim Senden einer speziell gestalteten Nachricht an einen nicht privilegierten Benutzer über den D-Bus.

Die Red Hat-Entwickler schließen auch nicht die Möglichkeit aus, die Sicherheitsanfälligkeit zum Organisieren der Codeausführung mit Root-Rechten zu verwenden.Die endgültige Möglichkeit eines solchen Angriffs ist jedoch noch nicht geklärt.

Über systemd

Für diejenigen, die Systemd nicht kennen Das kann ich dir sagen Dies ist ein Linux-Initialisierungssystem und ein Service-Manager Dazu gehören Funktionen wie der On-Demand-Daemon-Start, die Wartung von Automount- und Mount-Punkten, die Unterstützung von Snapshots und die Prozessverfolgung mithilfe von Linux-Kontrollgruppen.

Systemiert Bietet einen Registrierungsdämon und andere Tools und Dienstprogramme, die bei allgemeinen Systemverwaltungsaufgaben helfen. Lennart Poettering und Kay Sievers haben SystemD geschrieben, inspiriert von macOS launchd und Upstart, mit dem Ziel, ein modernes und dynamisches System zu schaffen.

Insbesondere bietet systemd aggressive Parallelisierungsfunktionen und eine abhängigkeitsbasierte Dienststeuerungslogik, sodass Dienste parallel gestartet werden können und die Startzeiten verkürzt werden. Diese beiden Aspekte waren in Upstart vorhanden, wurden jedoch durch systemd erweitert.

Systemd ist das Standard-Boot-System für wichtige Linux-Distributionen, ist aber abwärtskompatibel mit den SysV-Startskripten.

SysVinit ist ein Initialisierungssystem, das systemd vorausgeht und einen vereinfachten Ansatz zum Starten des Dienstes verwendet. Systemd verwaltet nicht nur die Systeminitialisierung, sondern bietet auch Alternativen zu anderen bekannten Dienstprogrammen wie cron und syslog.

Über die neue Systemd-Sicherheitslücke

Durch Manipulieren der Größe der über den D-Bus gesendeten Nachricht Ein Angreifer kann den Zeiger über die für den Stapel zugewiesenen Speichergrenzen hinaus bewegenunter Umgehung des Schutzes der "Stack Guard-Page", die auf dem Ersetzen einer Speicherseite am Rand basiert, die eine Ausnahme auslöst (Seitenfehler).

Der erfolgreiche Angriff wird unter Ubuntu 18.10 mit systemd 239 und unter CentOS 7.6 mit systemd 219 demonstriert.

Um dieses Problem zu umgehen, kann die Kompilierung in GCC mit der Option "-fstack-clash-protected" verwendet werden, die in Fedora 28 und 29 standardmäßig verwendet wird.

Es sollte beachtet werden, dass der Autor der MUSL-Systembibliothek im Jahr 2014 auf die Hauptprobleme der Architektur und des PID1-Handlers mit übermäßiger Inflation hingewiesen und die Machbarkeit der Implementierung eines PID1-Pegelreglers für die Bus Link-API in Frage gestellt hat, da dieser ein schwerwiegender Angriffsvektor ist und kann die Zuverlässigkeit des gesamten Systems nachteilig beeinflussen

Laut einem Sicherheitsforscher, der Bei einer Sicherheitsanfälligkeit ist eine Änderung des Stapelzeigers nur für nicht verwendete Speicherseiten möglich (nicht zugewiesen), mit dem die Codeausführung im Kontext des PID1-Prozesses nicht organisiert werden kann, ein Angreifer jedoch die PID1-Sperre mit einem anschließenden Übergang des Linux-Kernels in den Status "Panik" (im Fall des PID-Reglers) initiieren kann 1 Fehler, das gesamte System hängt).

In systemd ist ein Signalhandler installiert, der versucht, die Fehler des PID1-Prozesses abzufangen (Segmentierungsfehler) und die Shell zur Wiederherstellung startet.

Da jedoch während des Angriffs nicht duplizierte (nicht zugewiesene) Speicherseiten aufgerufen werden, kann der Kernel diesen Signalhandler nicht aufrufen und beendet den Prozess nur mit PID 1, was wiederum dazu führt, dass es unmöglich ist, weiter zu arbeiten und darauf einzugehen Der Status "Panik", daher ist ein Neustart des Systems erforderlich.

Es gibt bereits eine Lösung für das Problem

Wie jedes bereits beschriebene und gemeldete Sicherheitsproblem kann seine Veröffentlichung erst erfolgen, wenn das Problem gelöst wurde und Schwachstellen-Patch-Updates für SUSE / openSUSE, Fedora wurden bereits veröffentlicht, auch für Ubuntu und teilweise für Debian (Nur Debian Stretch).
Obwohl das Problem in RHEL unkorrigiert bleibt.