Eine Fallstudie zur Offenlegung von Lakebase Postgres
von Aaron Kobayashi, Mehmet D. Ince, Anurag Srivastava und Alexey Kondratov
Einige unserer besten Investitionen in die Sicherheit waren weder Tools noch Scanner. Sie lagen in Beziehungen. Databricks betreibt ein Bug-Bounty-Programm, weil der schnellste Weg, die Schwachstellen einer Plattform zu finden, darin besteht, talentierte, neugierige Menschen danach suchen zu lassen. Und wir wollen sicherstellen, dass eine Meldung in gutem Glauben auch eine entsprechende Reaktion erhält. Die meisten Meldungen sind eine stille Angelegenheit: Jemand findet einen Fehler, wir beheben ihn, und alle machen weiter.
Ab und zu wird aus einer dieser Meldungen eine wirklich gute Geschichte. Dies ist eine davon.
Vor einigen Wochen zeigte uns ein externer Sicherheitsforscher, Mehmet Ince, einen Speichersicherheitsfehler in einer Postgres-Erweiterung, die auf verwalteten Postgres-Plattformen wie Lakebase Postgres und Neon bereitgestellt wird. Warum es sich lohnt, darüber zu schreiben, liegt nicht nur an dem Fehler selbst. Es ist das, was drumherum geschah: wie unsere Erkennung seine Tests erfasste, wie schnell wir unsere Kunden schützen konnten und wie die eigentliche Behebung dorthin zurückkehrte, wo sie hingehört. In die Open-Source-Community, für alle, die dieselbe Erweiterung nutzen, nicht nur für uns.
Wenn Sie ein Sicherheitsteam leiten, eine verwaltete Open-Source-Infrastruktur betreiben oder einfach nur neugierig sind, wie eine gesunde Interaktion zwischen Sicherheitsforschern und Anbietern auf beiden Seiten aussieht, ist dieser Beitrag für Sie. Mehmet hat die tiefgehende technische Analyse der Ausnutzung auf seinem eigenen Blog veröffentlicht. Hier möchten wir über die Zusammenarbeit sprechen.
| Mehmets Blog verweist auf die Offenlegung von kundenzübergreifenden Daten auf einer anderen Plattform. Databricks betreibt Lakebase Postgres und Neon auf einer MicroVM-Architektur, die eine starke Sicherheitsgrenze zwischen Compute-Instanzen bietet. Mehmets Exploit hatte keine kundenzübergreifenden Auswirkungen auf Databricks. |
|---|
Das Ökosystem der Postgres-Erweiterungen ist ein Hauptgrund für seine Beliebtheit. Obwohl der Support je nach Anbieter variiert, erwarten Kunden von verwalteten Anbietern, dass sie die am häufigsten genutzten Kern- und Drittanbieter-Optionen unterstützen. Eine davon ist PostGIS, das Toolkit für Geodaten. Innerhalb von PostGIS gibt es eine kleinere, unscheinbare Erweiterung namens address_standardizer, die eine unstrukturierte Adresse wie 123 Main St in ein normalisiertes Format umwandelt.
Mehmet fand heraus, dass address_standardizer eine klassische Schwachstelle bei der Speichersicherheit aufwies: Ein Wert, den ein Aufrufer vollständig kontrolliert (Teil einer Grammatikregel, die der Aufrufer angeben kann), wurde verwendet, um in ein internes Array fester Größe zu indizieren – ohne Grenzwertprüfung. Wenn man ihm einen Wert außerhalb des gültigen Bereichs übergibt, kommt es zu einem unzulässigen Speicherzugriff.
Der wichtige Punkt bei einem verwalteten Postgres-Dienst ist, wer darauf zugreifen kann. address_standardizer gehört zu den Erweiterungen, die ein normaler Mandant installieren und nutzen kann. Es handelte sich also nicht um einen Fehler, für dessen Ausnutzung besondere Berechtigungen erforderlich waren. Eine normale Kundenrolle konnte die Funktion aufrufen und den anfälligen Codepfad erreichen. Genau diese Eigenschaft macht aus einem stillen, leicht zu übersehenden Fehler etwas, das ein Plattform-Team ernst nehmen muss.
Wir halten uns hier bei den Details zur Ausnutzung bewusst zurück. Mehmets Deep-Dive erklärt die Grundlagen ausführlich, und er macht das besser, als eine Zusammenfassung es könnte.
Von Mehmet D. Ince
Die Geschichte begann nicht als Schwachstellenforschung. In diesem Frühjahr fragte mein Team während eines internen Meetings, ob wir einige unserer PostgreSQL-Instanzen zu einem verwalteten Anbieter migrieren könnten. Als CTO von PRODAFT, einem europäischen Cyber-Bedrohungsanalyse-Unternehmen mit rund 50 Ingenieuren, gehört es zu meinen Aufgaben, dafür zu sorgen, dass wir unseren Kunden die sichersten Dienste anbieten.
Wir betreiben PostgreSQL seit mehr als einem Jahrzehnt selbst, aber ich hatte noch nie richtig untersucht, wie Anbieter von verwaltetem Postgres diese Dienste aus Sicherheitsaspekten bereitstellen. Ich beschäftige mich seit den frühen 2000er-Jahren mit der Erforschung von Schwachstellen. Daher nehme ich mir immer ein kleines Zeitfenster, um Sicherheitsanalysen durchzuführen und die Risiken besser zu verstehen, die wir eingehen, wenn wir unsere Infrastruktur um eine weitere Technologie erweitern. Es überrascht nicht, dass meine „schnellen Überprüfungen“ meist mit einem Bericht über eine kritische Schwachstelle im Posteingang von jemandem enden. Manche Gewohnheiten legt man nur schwer ab.
Nach einigen Tagen der Recherche stellte ich fest, dass fast jeder Anbieter im Grunde dieselben Postgres-Erweiterungen ausliefert. Eine Speicherbeschädigungs-Schwachstelle in einer weit verbreiteten Erweiterung ist im Grunde eine Speicherbeschädigungs-Schwachstelle in PostgreSQL selbst. Also wählte ich eine Erweiterung namens address_standardizer als mein Ziel aus – eine kleine PostGIS-Erweiterung, die praktisch überall verfügbar ist.
An einem Montagabend gegen 19 Uhr hier in London schickte mir Aaron völlig unerwartet eine E-Mail und fragte, ob die Aktivitäten, die die Produktionsalarme von Neon ausgelöst hatten, von mir stammten. Ich arbeitete gerade daran, meinen funktionierenden Exploit auf Neon-PostgreSQL-Instanzen zu übertragen, um zu sehen, ob ein einzelner, einfacher Fehler in einer kleinen, harmlosen Erweiterung dort tatsächlich einen Pfad zur Rechteausweitung eröffnen könnte. Ich hatte einen funktionierenden PoC, schickte ihm aber nur einen Screenshot. Dieser eine Screenshot reichte ihm aus, um sofort aktiv zu werden!
Ich melde Schwachstellen seit mehr als zwei Jahrzehnten verantwortungsvoll an Anbieter. Doch selbst nach all diesen Jahren ist es immer noch schwierig, die Auswirkungen und Risiken der Ergebnisse zu erklären, ohne viel Zeit mit der Suche nach dem richtigen Ansprechpartner zu verbringen. Ich muss sagen: Großes Lob an Aaron und das Sicherheitsteam von Databricks, dass sie so proaktiv auf Forscher zugehen und so schnell handeln!
Weitere Informationen finden Sie in Mehmets Beitrag.
Aus unserer Sicht ist dies ein Paradebeispiel dafür, wie eine koordinierte Offenlegung funktionieren sollte.
Mehmet teilte seine Belege, und bis zum Ende des Tages war der Bericht bei den richtigen Personen angekommen. Unsere Sicherheitsingenieure validierten ihn mit der exakten PostGIS-Version, die Neon ausliefert. Wir bestätigten, dass der anfällige Codepfad für eine normale Mandantenrolle erreichbar war, und behandelten ihn entsprechend.
Schon früh haben wir eine bewusste Entscheidung getroffen, die wir hier gerne hervorheben möchten, da sich jedes Plattform-Team irgendwann dieser Frage stellen muss: Ein Fehler in einer von Ihnen ausgelieferten Open-Source-Komponente ist immer noch Ihr Problem. Die Ursache lag zwar vorgelagert in PostGIS, aber das Risiko lag bei uns. Wir stellen diese Erweiterung den Mandanten standardmäßig zur Verfügung, also lag die Verantwortung für die Auswirkungen bei uns. Wir haben es nicht als „Drittanbieter-Problem“ abgetan. Stattdessen haben wir den Bericht angenommen, die Reaktion koordiniert und den Sicherheitsforscher belohnt, der ihn eingereicht hat.
Wir wollten auch nicht auf den Release-Zeitplan des Upstream-Projekts warten müssen, während unsere Kunden gefährdet waren. Unser Build-System für Erweiterungen ist bewusst so konzipiert, dass wir beliebige Patches auf jede Upstream-Postgres-Erweiterung anwenden können, bevor wir sie kompilieren und paketieren – sei es durch das Backporting eines Fixes oder das Deaktivieren eines riskanten Codepfads in unserem eigenen Build. Da diese Patches nachgelagert und nicht im Quellcode des Upstream-Projekts liegen, können wir unabhängig davon handeln, wann das Upstream-Projekt ein Release veröffentlicht. So konnten wir schnell handeln, um unsere Kunden zu schützen, und parallel daran arbeiten, das Ökosystem ordnungsgemäß zu reparieren.
Die Entwicklung einer dauerhaften Behebung erforderte einige Iterationen. Der erste Entwurf deckte nicht jeden Fall ab, und wir wollten uns lieber eine Woche mehr Zeit nehmen, um es richtig zu machen, als eine unvollständige Lösung auszuliefern. Der gehärtete Fix wurde bereitgestellt, um die Mandanten von Neon und Lakebase zu schützen, die selbst nichts unternehmen mussten.
Hier wird es interessant und wir hatten auch ein wenig Glück.
Die endgültige Behebung gehörte in PostGIS. Es ist ihr Code, ihr Release, ihre Entscheidung. Databricks dankt den PostGIS-Maintainern, die einen grundlegenden Teil der Geodaten-Welt größtenteils ehrenamtlich am Laufen halten. Mehmet sah das offensichtlich genauso und handelte entsprechend: Er spendete seine Belohnung an das PostGIS-Projekt und verdoppelte sie aus eigener Tasche. Damit floss die Belohnung direkt zurück in die ehrenamtliche Arbeit, auf deren Code die gesamte Branche für verwaltetes Postgres aufbaut. Unser Plan war einfach: Zuerst unsere Kunden schützen und dann mit Mehmet zusammenarbeiten, um die Ursache Upstream zu beheben, damit alle, die address_standardizer nutzen, davon profitieren, nicht nur Neon.
Dann machte ein Zufall die Sache komplizierter. Ungefähr zur gleichen Zeit wurde der zugrunde liegende Fehler Upstream als kleiner Fix für ein Speicherleck behoben – ohne CVE und ohne großes Aufsehen.
Wie sich herausstellte, deckte der Upstream-Fix nicht jeden Fall ab. Mehmet überprüfte genau, wo es haperte, und reichte die verbleibenden Teile wieder Upstream ein, wodurch die Lücke für die gesamte Community geschlossen wurde. Für die Kette wurde keine CVE vergeben, was eine ganz eigene kleine Lektion darüber ist, wie leicht ein wichtiger Fix zur Speichersicherheit als "geringfügige" Bereinigung in die Release Notes rutschen kann.
Die Erkenntnis, auf die es uns ankommt: Der Forscher konnte das Richtige mit der Ursache tun, Upstream erhielt einen vollständigen Fix und unsere Kunden waren bereits geschützt, während sich all das abspielte.
Wenn Sie einen Managed Service betreiben, der auf Open-Source-Komponenten basiert (eine verwaltete Datenbank, ein verwaltetes Irgendwas), ist die unangenehme Wahrheit in dieser Geschichte, dass Ihre Angriffsfläche Code umfasst, den Sie nicht geschrieben haben, und ein Bedrohungsmodell, für das sich die Autoren möglicherweise nie entschieden haben. Eine kleine, beliebte, unauffällige Erweiterung ist genau die Art von Ding, die sich leicht ausliefern und leicht vergessen lässt.
Einige Dinge, die für uns funktioniert haben und vielleicht auch für Sie hilfreich sind:
Wenn Sie ein Sicherheitsforscher sind, würden wir uns freuen, von Ihnen zu hören. Insbesondere dann, wenn Sie wie Mehmet echte, messbare Auswirkungen auf die Plattform aufzeigen können. Melden Sie dies über hackerone.com/databricks.
Vielen Dank an Mehmet Ince für einen gut dokumentierten Bericht in gutem Glauben und dafür, dass er mit der Ursache Upstream das Richtige getan hat. Vielen Dank an die PostGIS-Maintainer, deren Open-Source-Arbeit ein riesiger Teil der Geodatenwelt ist, die darauf angewiesen ist. Und vielen Dank an die Ingenieure von Neon und Lakebase, die schnell und besonnen aus einer Meldung einen bereitgestellten Fix gemacht haben.
An alle Forscher, die mit uns zusammenarbeiten, um die Plattform sicherer zu machen: Wir sehen Sie und sind Ihnen dankbar. Wir sehen uns auf HackerOne.
(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag
Abonnieren Sie unseren Blog und erhalten Sie die neuesten Beiträge direkt in Ihren Posteingang.