Die „Managed“-Grenze war keine Mauer
Managed PostgreSQL-Anbieter wie Supabase, Neon und Amazon Aurora bieten Kunden leistungsstarke administrative Rollen, enthalten ihnen jedoch echte Superuser-Privilegien vor. Sie zielen darauf ab, eine sichere Multi-Tenant-Umgebung bereitzustellen, in der Benutzer ihre Datenbank steuern können, ohne den zugrunde liegenden Host oder andere Kunden zu beeinträchtigen.
Anbieter erreichen dies durch den Einsatz benutzerdefinierter Erweiterungen oder Hooks. Diese Ebenen fangen potenziell gefährliche Operationen ab und blockieren sie—insbesondere solche, die das Dateisystem betreffen—selbst bei den höchsten kundenseitigen Rollen. Ein Anbieter könnte beispielsweise lo_export blockieren, eine native PostgreSQL-Funktion, die dazu dient, große Objekte auf die Festplatte des Servers zu schreiben.
Diese benutzerdefinierte Restriktionsebene kann jedoch ein falsches Sicherheitsgefühl erzeugen. Wenn das Schutzgeländer nur den Namen eines Befehls prüft und nicht dessen zugrunde liegende Funktionalität, kann ein Benutzer die Blockade umgehen. Die erneute Registrierung desselben internen C-Funktions-Alias unter einem neuen, nicht überwachten Namen umgeht die Blockliste und ermöglicht den Aufruf der ansonsten eingeschränkten Funktionalität. Dieses grundlegende Versäumnis bildete die Basis für eine signifikante Schwachstelle.
Ein neuer Name schlüpfte am Filter vorbei
Der gemeldete Bypass nutzte einen kritischen blinden Fleck in der namensbasierten Filterung aus. Die lo_export-Funktion von PostgreSQL schreibt große Datenbankobjekte direkt in Serverdateien. Managed-Anbieter, die diese Gefahr erkennen, blockieren lo_export normalerweise namentlich und verhindern so dessen Ausführung selbst für leistungsstarke Kundenrollen.
Ein Sicherheitsforscher demonstrierte, wie man dieses Schutzgeländer umgehen kann. Er stellte den Zugriff auf die zugrunde liegende interne Routine mithilfe des LANGUAGE internal-Mechanismus von PostgreSQL wieder her. Dies ermöglichte es ihm, eine neue Funktion mit einem nicht überwachten Namen zu definieren, die auf dieselbe Backend-C-Implementierung verwies wie das blockierte lo_export.
Diese Technik klonte effektiv die gefährliche Fähigkeit unter einem anderen Label und umging so die Sicherheitserweiterung des Anbieters. Sobald diese Alias-Funktion verfügbar war, konnte der Forscher beliebige Dateien auf die Festplatte des Datenbankservers schreiben.
Diese Schwachstelle verdeutlicht eine grundlegende Schwäche in Sicherheitsmodellen, die sich ausschließlich auf namensbasierte Filterung verlassen. Alternative Namen können auf dieselbe zugrunde liegende Implementierung verweisen, was bedeutet, dass die Überprüfung des Labels nicht gleichbedeutend mit der Kontrolle der Funktionalität ist. Die Erweiterungen der Anbieter blockierten das Wort „lo_export“, aber nicht die Aktion des Schreibens von Dateien auf den Server, wodurch ein kritischer Designfehler offen blieb.
Von SQL-Berechtigung zu Host-Level-Code
Die replizierte lo_export-Funktion, die nun unter einem nicht blockierten Alias operierte, bot ein kritisches Primitiv: die Fähigkeit, beliebige Dateien auf den PostgreSQL-Host zu schreiben. Angreifer nutzten dies, um eine kompilierte Shared Library (.so-Datei) auf die Festplatte des Servers zu laden.
Mit der schädlichen Bibliothek am richtigen Ort bestand der nächste Schritt darin, sie als PostgreSQL C-Sprachfunktion zu registrieren. Dies wird über CREATE FUNCTION ... LANGUAGE C erreicht, was PostgreSQL anweist, eine spezifische Funktion aus der Shared Library direkt in die SQL-Umgebung der Datenbank zu laden und verfügbar zu machen.
Als ein Angreifer diese neu registrierte C-Sprachfunktion über eine einfache SQL-Abfrage aufrief, führte die Datenbank seinen beliebigen Code aus. Entscheidend ist, dass dieser Code mit den Betriebssystemberechtigungen des PostgreSQL-Prozesses selbst auf dem Datenbank-Host ausgeführt wurde. Dies ist kein Root-Zugriff und gewährt auch nicht automatisch Zugriff auf die Daten anderer Kunden, da Instanzen normalerweise isoliert sind.
Die Host-Ausführung bietet jedoch einen bedeutenden Ausgangspunkt. Sie ermöglicht Persistenz auf dem Server, erlaubt eine umfassende Systemaufzählung und kann Versuche zur lateralen Bewegung innerhalb der Infrastruktur des Anbieters erleichtern. Der Schweregrad hängt stark von den spezifischen Isolationsmechanismen und Netzwerkkonfigurationen jedes verwalteten Dienstes ab. Eine detaillierte technische Analyse finden Sie unter Breaking the PostgreSQL Superuser Guardrails: Attacking Security-Hardening Extensions.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Anbieter müssen die von ihnen verkaufte Grenze sichern
Supabase reagierte schnell und meldete Patches für vier kritische Probleme. Andere Anbieter boten langsamere oder unklare öffentliche Antworten, während das PostgreSQL-Kernteam die Verantwortung direkt bei den Dienstanbietern sah und betonte, dass das Sicherheitsmodell von PostgreSQL davon ausgeht, dass superuser interne Funktionen kontrolliert.
Leser, die tiefere Einblicke suchen, sollten Mehmet Inces grundlegende Forschung „Breaking the PostgreSQL Superuser Guardrails“ konsultieren. Das supautils-Projekt bietet ebenfalls eine wichtige Referenz, neben der detaillierten Dokumentation von Supabase zu Rollen und nicht unterstützten Vorgängen, die nun diese Lektionen widerspiegeln.
Dieser Vorfall ist eine deutliche Lektion für Anbieter. Das Blockieren gefährlicher Vorgänge nach Namen erweist sich als unzureichend. Robuste Sicherheit erfordert: - strenge Kontrollen über interne und C-Sprach-Bindings - sorgfältige Katalogberechtigungen - stärkere Isolation auf Betriebssystemebene
Diese Maßnahmen, nicht einfach nur längere Blocklisten, sind für die Sicherung der verwalteten Grenze, die sie verkaufen, unerlässlich. Die Integrität von Cloud PostgreSQL hängt davon ab, dass Anbieter die von ihnen versprochenen Grenzen durchsetzen.
Häufig gestellte Fragen
Was war die verwaltete PostgreSQL-Schwachstelle?
Ein Forscher umging die Einschränkungen der Anbieter, indem er eine gefährliche interne PostgreSQL-Funktion unter einem Namen registrierte, den die Filter der Anbieter nicht blockierten.
Hat die Schwachstelle die Datenbankinhalte anderer Kunden offengelegt?
Nicht automatisch. Die demonstrierte Eskalation ermöglichte die Codeausführung als PostgreSQL-Betriebssystembenutzer auf dem Datenbank-Host, was eher einen Ausgangspunkt schuf als sofortigen Zugriff auf die Daten anderer Mandanten.
War dies eine Schwachstelle im PostgreSQL-Kern?
Das PostgreSQL-Sicherheitsteam charakterisierte es als ein Problem auf Anbieterseite: Verwaltete Dienste müssen die von ihnen auferlegten Berechtigungsgrenzen sicher durchsetzen.
Was sollten verwaltete PostgreSQL-Anbieter ändern?
Sie sollten gefährliche interne und C-Sprach-Funktionsbindungen einschränken, Katalogberechtigungen härten und Datenbankprozesse auf Betriebssystemebene isolieren.