Über eine Schwachstelle ist das nicht

Bild
Ende März 2019 veröffentlichte das amerikanische Unternehmen Trustwave, das sich mit Cybersicherheits- und Bedrohungsschutzdiensten befasst, eine Meldung über eine Sicherheitsanfälligkeit im PostgreSQL-DBMS, das in allen Versionen von PostgreSQL 9.3 bis Version 11.2 vorhanden ist. Diese Sicherheitsanfälligkeit wurde in der Datenbank für Sicherheitsanfälligkeiten in Bezug auf Informationssicherheit in CVE (Common Vulnerabilities and Exposures) unter der Nummer CVE-2019-9193 registriert . Diese Meldung sorgte für großes Aufsehen, da diese Sicherheitsanfälligkeit gemäß dem CVSS-Schwachstellenbewertungssystem (Common Vulnerability Scoring System) auf einer 10-Punkte-Skala mit 9,0 bewertet wurde.


Den Sicherheitslücken wurden folgende Merkmale zugewiesen:


  • Auswirkungen auf die Vertraulichkeit (Einfluss auf die Vertraulichkeit) - Die vollständige Offenlegung von Informationen führt zur Offenlegung aller Systemdateien.
  • Auswirkungen auf die Integrität (Auswirkungen auf die Integrität) - Ein vollständiger Verlust des Systemschutzes, wodurch das gesamte System gefährdet wird.
  • Auswirkungen auf die Verfügbarkeit - Die Verfügbarkeit einer Ressource ist nicht verfügbar.
  • Die Zugriffskomplexität ist gering. Die Verwendung erfordert nur sehr wenig Wissen oder Fähigkeiten.
  • Authentifizierung - Ein Angreifer muss sich beim System anmelden, z. B. über die Befehlszeile oder über eine Desktopsitzung oder eine Weboberfläche.
  • Erhaltener Zugang - Nr.
  • Sicherheitsanfälligkeitstyp (en) (Art der Sicherheitsanfälligkeit) - Codeausführung.

Lassen Sie uns nun herausfinden, was wirklich passiert.


Im Jahr 2013 wurde in PostgreSQL 9.3 wieder ein Commit hinzugefügt, mit dem Sie ähnlich wie mit dem Befehl \ copy meta in psql Daten zwischen PostgreSQL-Tabellen und regulären Dateien im Dateisystem verschieben können. COPY TO kopiert den Inhalt der Tabelle in die Datei und COPY FROM - aus der Datei in die Tabelle (fügt Daten zu den bereits in der Tabelle enthaltenen hinzu). Im Gegensatz zum Meta-Befehl \ copy, der auf dem Client implementiert ist, ist der Befehl COPY..TO / FROM auf der Serverseite implementiert. Der COPY-Befehl verfügt über einen optionalen PROGRAM-Parameter 'command', mit dem der Server den 'command' ausführen und die Standardausgabe an den PostgreSQL-Server übergeben kann oder umgekehrt. Dieser Parameter verursachte die Panik und die Meldung über die Sicherheitsanfälligkeit, da Sie laut Trustwave mit diesem Befehl beliebigen Code im Kontext des Benutzers des Betriebssystems ausführen können. Dies ist jedoch genau das, was die Entwickler beabsichtigt haben! Bei dieser Gelegenheit gab es einen offiziellen Beitrag der PostgreSQL Global Development Group (PGDG) sowie Korrespondenz in der pgsql-allgemeinen E - Mail- Liste (CVE-2019-9193 über COPY FROM / TO PROGRAM ) und Kommentare führender Entwickler, zum Beispiel Magnus Hagander, in seinem Blog .


Aber um das Wesentliche zu verstehen, sind die Details wichtig. In der Dokumentation dazu wird Folgendes geschrieben: " Beachten Sie, dass der Befehl über die Befehlsshell gestartet wird. Wenn Sie also Argumente von einer nicht vertrauenswürdigen Quelle an diesen Befehl übergeben möchten, müssen Sie alle Sonderzeichen, die in der Shell eine besondere Bedeutung haben, sorgfältig entfernen um sie zu überprüfen. Aus Sicherheitsgründen ist es am besten, sich auf eine feste Befehlszeile zu beschränken oder Benutzern zumindest nicht zu erlauben, beliebigen Inhalt einzugeben . "


Darüber hinaus heißt es in der Dokumentation, dass nur Datenbank-Superuser den COPY-Befehl mit einer Datei oder einem externen Befehl ausführen dürfen oder (in Version 11 erschienen) Mitglieder der integrierten Rollen pg_read_server_files, pg_write_server_files oder pg_execute_server_program, da Sie damit alle Dateien lesen / schreiben und ausführen können Programme, auf die der Server Zugriff hat. Die Ausführung eines Befehls in PROGRAM kann durch andere Zugriffskontrollmechanismen eingeschränkt werden, die im Betriebssystem ausgeführt werden, z. B. SELinux.


Strukturell gibt es keine Sicherheitsgrenze zwischen dem Datenbank-Superuser und dem Benutzer des Betriebssystems, in dessen Auftrag der Serverprozess des Servers ausgeführt wird. Die in PostgreSQL 9.3 hinzugefügten Funktionen für COPY ... PROGRAM haben keine der oben genannten Änderungen geändert, sondern einen neuen Befehl innerhalb derselben Sicherheitsgrenzen hinzugefügt, die bereits vorhanden waren. Daher kann der PostgreSQL-Server nicht als Superuser des Betriebssystems (z. B. root) ausgeführt werden.


Die Funktion COPY..TO / FROM ... PROGRAM bietet selbst unbegrenzte Möglichkeiten für Datenmanipulation, Datennachbearbeitung, Datenkomprimierung im laufenden Betrieb usw. Und die Verwendung solcher nützlicher Werkzeuge zu verbieten, wäre falsch. Beispiele für das Konstrukt COPY..TO / FROM ... PROGRAM finden Sie in Michael Paquiers Blog .


Eine wichtige Schlussfolgerung aus dieser Geschichte ist, dass beim Entwerfen und Erstellen von Datenbanken nicht nur die funktionalen Merkmale, sondern auch die Informationssicherheit berücksichtigt und die folgenden Regeln befolgt werden müssen:


  • Geben Sie beim Erstellen normaler Benutzer in der Datenbank keine Superuser-Berechtigungen, sondern nur der Benutzer des Postgres-Betriebssystems, für das der Server gestartet wird, fungiert in der Datenbank als Superuser. In diesem Fall gibt es keine Eskalation von Berechtigungen. Wenn Sie einem normalen Datenbankbenutzer die Superuser-Berechtigung erteilen, entspricht dies der Erteilung der Berechtigungen, die der Postgres-Benutzer im Betriebssystem hat, an den Benutzer.
  • Verwenden Sie die Funktionen von pg_hba.conf, um sicherzustellen, dass sich kein Superuser remote anmelden kann.
    Wenn die Datei pg_hba.conf keine vorherigen Zeilen mit "host" enthält, verhindert der folgende Eintrag, dass der Benutzer von postgres von einer beliebigen Adresse aus eine Verbindung mit einer Datenbank unter Verwendung des TCP / IP-Protokolls herstellt.

    # TYPE DATABASE USER ADDRESS METHOD host all postgres 0.0.0.0/0 reject 
  • Verwenden Sie in PostgresSQL erweiterte Informationssicherheitstechniken wie den CIS PostgreSQL-Benchmark und das PostgreSQL Security Technical Implementation Guide (STIG) .
  • Verwenden Sie zertifizierte Produkte, für die die Einhaltung der funktionalen Anforderungen für Informationssicherheit und das Vertrauen in Informationssicherheitstools bestätigt wurde.

Daher haben wir herausgefunden, dass CVE-2019-9193 keine Sicherheitslücke ist. Aber du solltest dich nicht entspannen. Verpassen Sie keine Informationen zu Updates und neuen Nebenversionen, die identifizierte Schwachstellen korrigieren , ohne die kein einziges großes Projekt auskommt.

Source: https://habr.com/ru/post/de448750/


All Articles