Une étude de cas sur la divulgation de vulnérabilité pour Lakebase Postgres
par Aaron Kobayashi, Mehmet D. Ince, Anurag Srivastava et Alexey Kondratov
Certains de nos meilleurs investissements en matière de sécurité n'ont pas été des outils ou des scanners. Ils ont été consacrés aux relations humaines. Databricks propose un programme de bug bounty car le moyen le plus rapide de trouver les points faibles d'une plateforme est de laisser des personnes talentueuses et curieuses les chercher, et de s'assurer que lorsqu'elles trouvent quelque chose, un rapport de bonne foi reçoive une réponse de bonne foi. La plupart des rapports sont des transactions discrètes : quelqu'un trouve un bogue, nous le corrigeons, et tout le monde passe à autre chose.
De temps en temps, l'un d'eux se transforme en une histoire vraiment passionnante. En voici une.
Il y a quelques semaines, un chercheur externe, Mehmet Ince, nous a signalé une faille de sécurité liée à la gestion de la mémoire dans une extension Postgres intégrée aux plateformes Postgres gérées, notamment Lakebase Postgres et Neon. Ce qui mérite d'être raconté, ce n'est pas seulement le bogue en soi. C'est tout ce qui s'est passé autour : comment nos systèmes de détection ont repéré ses tests, la rapidité avec laquelle nous avons pu protéger nos clients, et comment le correctif final a été partagé là où il devait l'être. Dans le monde de l'open source, pour que tout le monde puisse en bénéficier, pas seulement nous.
Si vous dirigez une équipe de sécurité, gérez une infrastructure open source managée, ou si vous êtes simplement curieux de savoir à quoi ressemble une relation saine entre un chercheur et un fournisseur des deux côtés, cet article est pour vous. Mehmet a détaillé l'analyse technique approfondie de l'exploitation sur son propre blog. Ici, nous voulons plutôt parler de la collaboration.
| Le blog de Mehmet fait référence à une exposition de données entre clients sur une autre plateforme. Databricks exécute Lakebase Postgres et Neon sur une architecture microVM qui offre une frontière de sécurité robuste entre les instances de calcul. L'exploit de Mehmet n'a eu aucun impact sur les données des clients de Databricks. |
|---|
L'écosystème d'extensions de Postgres est l'un des principaux moteurs de sa popularité. Bien que le support varie selon les fournisseurs, les clients s'attendent à ce que les offres managées prennent en charge les options de base et tierces les plus utilisées. L'une d'elles est PostGIS, la boîte à outils géospatiale. Au sein de PostGIS se trouve une extension plus petite et plus discrète appelée address_standardizer, qui transforme une adresse non structurée comme 123 Main St en un format normalisé.
Mehmet a découvert que address_standardizer présentait une faille classique de gestion de la mémoire : une valeur entièrement contrôlée par l'appelant (faisant partie d'une « règle » de grammaire que l'appelant peut fournir) était utilisée pour indexer un tableau interne de taille fixe sans vérification des limites. Si vous lui fournissez une valeur hors limites, vous obtenez un accès mémoire hors limites.
L' élément crucial pour un service Postgres managé est de savoir qui peut y accéder. address_standardizer fait partie des extensions qu'un utilisateur standard peut installer et utiliser. Il ne s'agissait donc pas d'un bogue nécessitant des privilèges spéciaux pour être exploité. Un rôle client ordinaire pouvait appeler la fonction et atteindre le chemin de code vulnérable. C'est précisément ce qui transforme un bogue discret et facile à ignorer en un problème qu'une équipe de plateforme doit prendre très au sérieux.
Nous choisissons délibérément de ne pas entrer dans les détails de l'exploitation ici. L'analyse approfondie de Mehmet explique le mécanisme en détail, et il le fait bien mieux qu'un simple résumé.
Par Mehmet D. Ince
L'histoire n'a pas commencé par une recherche de vulnérabilités. Ce printemps, lors d'une réunion interne, mon équipe s'est demandé si nous pouvions migrer quelques-unes de nos instances PostgreSQL vers un fournisseur managé. En tant que CTO de PRODAFT, une entreprise européenne de renseignement sur les menaces comptant environ 50 ingénieurs, l'une de mes responsabilités est de veiller à ce que nous fournissions les services les plus sécurisés possibles à nos clients.
Nous gérions nous-mêmes PostgreSQL depuis plus d'une décennie, mais je n'avais jamais vraiment analysé la sécurité de la manière dont les fournisseurs de Postgres managé proposaient ces services. Je fais de la recherche de vulnérabilités depuis le début des années 2000, alors je m'accorde toujours un petit moment pour faire des recherches de sécurité et mieux comprendre les risques que nous prenons en ajoutant simplement une nouvelle technologie à notre infrastructure. Sans surprise, mes « analyses rapides » ont tendance à se terminer par un rapport de vulnérabilité critique dans la boîte de réception de quelqu'un. Certaines habitudes ont la vie dure.
Après quelques jours de recherche, j'ai réalisé que presque tous les fournisseurs proposent à peu près les mêmes extensions Postgres. Une vulnérabilité de corruption de mémoire dans une extension largement déployée équivaut en réalité à une vulnérabilité de corruption de mémoire dans PostgreSQL lui-même. J'ai donc choisi comme cible une extension nommée address_standardizer, une petite extension PostGIS disponible absolument partout.
Un lundi soir vers 19 heures, ici à Londres, Aaron m'a envoyé un e-mail de manière assez inattendue pour me demander si l'activité qui avait déclenché les alertes de production de Neon venait de moi. J'étais en train d'adapter mon exploit fonctionnel sur des instances Neon PostgreSQL pour voir si un simple bogue dans une petite extension inoffensive pouvait réellement y ouvrir une voie d'élévation de privilèges. J'avais un PoC fonctionnel, mais je ne lui ai envoyé qu'une capture d'écran. Cette simple capture d'écran a suffi pour qu'il commence à agir !
Je signale des vulnérabilités aux fournisseurs de manière responsable depuis plus de deux décennies, et même après toutes ces années, il est toujours difficile d'expliquer l'impact et les risques des découvertes sans passer beaucoup de temps à chercher le bon contact à qui s'adresser. Je dois dire bravo à Aaron et à l'équipe de sécurité de Databricks pour avoir contacté proactivement des chercheurs de cette manière et avoir agi si rapidement !
Consultez l'article de Mehmet pour plus d'informations.
De notre côté, c'est un cas d'école de divulgation coordonnée qui s'est déroulée exactement comme elle le devrait.
Mehmet a partagé ses preuves et, avant la fin de la journée, le rapport a été transmis aux bonnes personnes, nos ingénieurs en sécurité l'ayant validé par rapport à la version exacte de PostGIS fournie par Neon. Nous avons confirmé que le chemin de code vulnérable était accessible par un rôle d'utilisateur standard et nous l'avons traité en conséquence.
Dès le départ, nous avons pris une décision délibérée qu'il nous semble important de souligner, car c'est une question à laquelle chaque équipe de plateforme est un jour confrontée : un bogue dans un composant open source que vous fournissez reste votre problème. La cause première se situait en amont dans PostGIS, mais l'exposition nous concernait directement. Nous proposons cette extension par défaut aux utilisateurs, l'impact était donc de notre responsabilité. Nous ne l'avons pas écartée en la qualifiant de « tierce ». Au lieu de cela, nous avons accepté le rapport, piloté la réponse et récompensé le chercheur qui l'avait signalé.
Nous ne voulions pas non plus dépendre du calendrier de publication de la version officielle en amont alors que nos clients étaient exposés. Notre système de build d'extensions est conçu pour nous permettre d'appliquer un ensemble de correctifs sur n'importe quelle extension Postgres en amont avant de la compiler et de l'intégrer, qu'il s'agisse de rétro-porter un correctif ou de désactiver un chemin de code risqué dans notre propre build. Comme cet ensemble de correctifs est géré en aval plutôt que dans le code source d'origine, nous pouvons agir indépendamment des publications officielles. Nous avons ainsi pu agir rapidement pour protéger nos clients et travailler en parallèle à la résolution définitive du problème pour l'ensemble de l'écosystème.
La mise au point d'un correctif durable a nécessité plusieurs étapes. La première version ne couvrait pas tous les cas, et nous avons préféré prendre une semaine de plus pour bien faire les choses plutôt que de déployer une solution incomplète. Le correctif renforcé a été déployé pour protéger les utilisateurs de Neon et Lakebase, qui n'ont eu aucune action à entreprendre de leur côté.
C'est là que cela devient intéressant, et que nous avons eu un peu de chance.
Le correctif officiel devait être intégré dans PostGIS. C'est leur code, leur version, leur décision. Databricks remercie les mainteneurs de PostGIS, qui font fonctionner bénévolement un élément fondamental du monde géospatial. Mehmet a partagé ce sentiment et a agi en conséquence : il a fait don de sa prime au projet PostGIS et a versé la même somme de sa poche, reversant ainsi directement la récompense aux bénévoles dont le code soutient toute l'industrie du Postgres managé. Notre plan était simple : protéger d'abord nos clients, puis travailler avec Mehmet pour corriger la cause première en amont afin que tous ceux qui utilisent address_standardizer en bénéficient, et pas seulement Neon.
Puis une coïncidence a compliqué les choses. À peu près au même moment, le bogue sous-jacent a été corrigé en amont, sous la forme d'une simple correction de fuite de mémoire, sans CVE et sans faire de bruit.
Il s'est avéré que le correctif en amont ne couvrait pas tous les cas. Mehmet a validé précisément là où il faisait défaut et a soumis les éléments restants en amont, comblant ainsi la lacune pour l'ensemble de la communauté. Aucun CVE n'a été attribué à cette chaîne, ce qui constitue en soi une petite leçon sur la facilité avec laquelle un correctif important de sécurité de la mémoire peut se glisser dans une note de version sous la forme d'un nettoyage « mineur ».
Ce qu'il faut retenir et qui nous importe : le chercheur a pu faire ce qu'il fallait concernant la cause profonde, le projet en amont a bénéficié d'un correctif complet, et nos clients étaient déjà protégés pendant que tout cela se déroulait.
Si vous gérez un service géré basé sur des composants open source (une base de données gérée, ou n'importe quel autre service géré), la vérité inconfortable de cette histoire est que votre surface d'attaque inclut du code que vous n'avez pas écrit et un modèle de menace auquel ses auteurs n'ont peut-être jamais consenti. Une petite extension populaire et endormie est exactement le genre de chose facile à déployer et facile à oublier.
Voici quelques approches qui ont fonctionné pour nous, et qui pourraient fonctionner pour vous :
Si vous êtes chercheur en sécurité, nous aimerions sincèrement avoir de vos nouvelles. Surtout lorsque vous pouvez démontrer un impact réel et mesurable sur la plateforme, comme l'a fait Mehmet. Signalez-le via hackerone.com/databricks.
Merci à Mehmet Ince pour son signalement bien documenté et de bonne foi, et pour avoir fait ce qu'il fallait concernant la cause profonde en amont. Merci aux mainteneurs de PostGIS, dont le travail open source constitue une part immense du monde géospatial qui en dépend. Et merci aux ingénieurs de Neon et Lakebase qui ont rapidement et calmement transformé un signalement en un correctif déployé.
À tous les chercheurs qui travaillent avec nous pour rendre la plateforme plus sûre : nous vous voyons et nous vous en sommes reconnaissants. À bientôt sur HackerOne.
(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original
Abonnez-vous à notre blog et recevez les derniers articles directement dans votre boîte mail.