An Systemd scheiden sich ja ohnehin die Geister. Nun machte der Init-Nachfolger abermals Schlagzeilen, diesmal aufgrund gravierender Sicherheitsmängel.
Aktuell handelt es sich gleich um drei Schwachstellen, die es einem Angreifer erlauben, Rootrechte auf dem System zu erlangen. Die Sicherheitslücke betrifft alle auf Systemd basierenden Linux-Distributionen.
Doch lassen sich die Fehler nicht auf allen Systemen durch Angreifer ausnutzen. So sind die Suse-Produkte SLES 15 und Open Suse Leap 15 sowie Fedora 28 und 29 vor den Attacken geschützt, da ihre Userspace-Software mit der GCC-Option »-fstack-clash-protection« übersetzt ist. Das schützt gegen die von der Firma Qualys entdeckte Stack-Clash-Attacke, bei der allozierte Stack- und Heap-Speicherbereiche kollidieren [1].
Eigentlich sollte die Stack Guard Page des Linux-Kernels solche Situationen und damit Rechte-Ausweitungen durch Speichermanipulationen verhindern. Sie trennt Regionen des Speichers, die zu verschiedenen Prozessen im Userspace gehören. Die Stack-Clash-Attacke umgeht aber diesen Schutz. Nutzer von Distributionen, die ohne besagte Option übersetzt sind, sollten dringend entsprechende Sicherheitsupdates einspielen.
Zwei der drei Schwachstellen (CVE-2018-16864, CVE-2018-16865) gehen auf Fehler in der Speicherverwaltung von Systemd zurück. Bei dem dritten Problem (CVE-2018-16866) handelt es sich um einen Pufferüberlauf in der Systemd-Journald-Funktion. Kurios an diesen Schwachstellen ist, dass sie schon seit Jahren im Programmcode schlummern. Einige der Fehler wurden jedoch erst durch spätere Änderungen ausnutzbar.
Gefunden haben die Schwachstellen Qualys-Mitarbeiter per Zufall. Auf der Suche nach einem Exploit für Mutagen Astronomy (CVE-2018-14634) stellten sie fest, dass der Journald-Prozess abstürzt, sobald er mehrere Megabyte große Kommandozeilen-Argumente erhält.
Ursache des Fehlers ist ein ungeschützter »alloca()«-Aufruf im Code. Alloca alloziert Speicher, der automatisch wieder freigegeben und auf dem Stack und nicht auf dem Heap alloziert wird. Weil es keine Kontrollen für Overflows kennt, ist »alloca()« schon prinzipiell recht unsicher. Ihr ungeschützter Aufruf erlaubt eine Stack-Clash-Attacke auf anfälligen Systemen.
Bei der Arbeit an einem Proof-of-Concept-Exploit für dieses erste Problem stießen die Forscher dann auf die beiden anderen Schwachstellen. Dabei handelt es sich zunächst um einen zweiten unachtsamen Aufruf der Alloca-Funktion. Hierzu kommt es in der »journal_file_append_entry()«-Funktion. Auch dieses Problem erlaubt eine Stack-Clash-Attacke.
Die dritte Sicherheitslücke findet sich direkt im Journald-Code. Journald ist die Service-Unit von Systemd, die besonders für das Logging in das zentrale Journal zuständig ist. Standardmäßig sammelt sie dort die Logmeldungen des Kernels, des Systems, der Service-Units und auch von Stdout und Stderr.
In diesem Code tritt ein Out-of-Bound-Read-Fehler auf. Das Qualys-Advisory [2] weist darauf hin, dass die Schwachstellen CVE-2018-16865 und CVE-2018-16866 für eine Attacke kombinierbar sind. So haben die Forscher einen Exploit entwickelt, dem es gelingt, auf i386-Systemen innerhalb von nur zehn Minuten eine Rootshell zu öffnen. Auf AMD64-Systemen dauert das zwar etwas länger, aber auch hier hat der Angreifer innerhalb von lediglich 70 Minuten auf dem Testsystem eine Rootshell geöffnet. Qualys wird diesen Exploit in naher Zukunft veröffentlichen.
Infos
-
Stack-Clash: https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
-
Qualys Security Advisory: https://www.openwall.com/lists/oss-security/2019/01/09/3






