Eine Denial-of-Service-Sicherheitslücke gefunden, die systemd betrifft

Vor einigen Tagen wurde die Nachricht veröffentlicht, dass das Ermittlungsteam von Qualys hat eine Denial-of-Service-Sicherheitslücke entdeckt aufgrund der Stack-Erschöpfung in systemd, sodass jeder nicht privilegierte Benutzer diese Sicherheitsanfälligkeit ausnutzen kann systemd zu blockieren.

Verletzlichkeit bereits katalogisiert als (CVE-2021-33910) Es wird erwähnt, dass es sich auf systemd auswirkt. Dies wird durch einen Fehler verursacht, wenn versucht wird, ein Verzeichnis mit einer Pfadgröße von mehr als 8 MB über FUSE zu mounten und in dem der Steuerungsinitialisierungsprozess (PID1) keinen Stapelspeicher mehr hat und sich blockiert, wodurch die System in einem "Panik"-Zustand.

Diese Schwachstelle wurde in systemd v220 (Apr 2015) durch den Commit 7410616c ("kernel: rework unit name manipulation and valid logic") eingeführt, der ein strdup() auf dem Heap durch ein strdupa() in der Batterie ersetzte. Die erfolgreiche Ausnutzung dieser Schwachstelle ermöglicht es jedem unprivilegierten Benutzer, Denial-of-Service durch Kernel-Panik zu verursachen.

Sobald das Qualys-Forschungsteam die Schwachstelle bestätigte, beteiligte sich Qualys an der verantwortungsvollen Offenlegung der Schwachstelle und stimmte sich mit dem Autor und Open-Source-Distributionen ab, um die Schwachstelle bekannt zu geben.

Die Forscher erwähnen das das Problem im Zusammenhang mit CVE-2021-33910 entsteht dadurch, dass systemd überwacht und analysiert den Inhalt von / proc / self / mountinfo und es behandelt jeden Einhängepunkt in der Funktion unit_name_path_escape(), was bewirkt, dass eine Operation namens "strdupa()" ausgeführt wird, die dafür sorgt, dass die Daten auf dem Stack statt auf dem Heap zugewiesen werden.

Deshalb seit Die maximal zulässige Stapelgröße ist begrenzt durch die Funktion "RLIMIT_STACK", Wenn ein zu langer Pfad zum Mount-Punkt verarbeitet wird, hängt der Prozess "PID1" auf was zum Stoppen des Systems führt.

Darüber hinaus erwähnen sie, dass für einen funktionierenden Angriff das einfachste FUSE-Modul in Kombination mit der Verwendung eines stark verschachtelten Verzeichnisses als Einhängepunkt verwendet werden kann, dessen Pfadgröße 8 MB überschreitet.

Auch Es ist wichtig zu erwähnen, dass die Qualys-Forscher einen besonderen Fall erwähnen mit Verletzlichkeit, da vor allem mit systemd version 248 ist der Exploit nicht funktionsfähig aufgrund eines Fehlers im systemd-Code, der dazu führt, dass / proc / self / mountinfo fehlschlägt. Interessant ist auch, dass es 2018 zu einer ganz ähnlichen Situation kam, als beim Versuch, einen Exploit für die Schwachstelle CVE-2018-14634 im Linux-Kernel zu schreiben, in der Qualys-Forscher drei weitere kritische Schwachstellen in systemd fanden.

Über Verwundbarkeit das Red Hat-Team erwähnte Jedes Produkt, das RHEL-kompatibel ist, ist möglicherweise ebenfalls betroffen.

Dies beinhaltet:

  • Produktcontainer, die auf RHEL- oder UBI-Container-Images basieren. Diese Images werden regelmäßig aktualisiert und der Containerstatus, der anzeigt, ob ein Fix für diesen Fehler verfügbar ist, kann im Container Health Index eingesehen werden, der Teil des Red Hat Container Catalog (https://access.redhat.com/containers) ist. .
  • Produkte, die Pakete aus dem RHEL-Kanal abrufen. Stellen Sie sicher, dass das zugrunde liegende Red Hat Enterprise Linux systemd-Paket in diesen Produktumgebungen auf dem neuesten Stand ist.

Aufgrund der Breite der Angriffsfläche dieser Schwachstelle, Qualys empfiehlt Benutzern, die entsprechenden Patches anzuwenden (die bereits vor einigen Tagen veröffentlicht wurden) sofort für diese Schwachstelle.

Wie bereits erwähnt tritt das Problem seit systemd 220 (Apr 2015) auf und wurde bereits behoben das Hauptrepositorium von systemd und wurde bei den meisten Distributionen behoben Linux main sowie seine Derivate können Sie den Status in den folgenden Links überprüfen (Debian, Ubuntu, Fedora, RHEL, Suse, Bogen).

Schließlich wenn Sie mehr darüber wissen möchten zu dieser Sicherheitsanfälligkeit können Sie die Details überprüfen im folgenden Link.


Schreiben Sie den ersten Kommentar

Hinterlasse einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert mit *

*

*

  1. Verantwortlich für die Daten: Miguel Ángel Gatón
  2. Zweck der Daten: Kontrolle von SPAM, Kommentarverwaltung.
  3. Legitimation: Ihre Zustimmung
  4. Übermittlung der Daten: Die Daten werden nur durch gesetzliche Verpflichtung an Dritte weitergegeben.
  5. Datenspeicherung: Von Occentus Networks (EU) gehostete Datenbank
  6. Rechte: Sie können Ihre Informationen jederzeit einschränken, wiederherstellen und löschen.