Un caso di studio sulla divulgazione di Lakebase Postgres
di Aaron Kobayashi, Mehmet D. Ince, Anurag Srivastava e Alexey Kondratov
Alcuni dei nostri migliori investimenti nella sicurezza non sono stati strumenti o scanner. Sono stati nelle relazioni. Databricks gestisce un programma di bug bounty perché il modo più rapido per trovare i punti deboli di una piattaforma è lasciare che persone di talento e curiose li cerchino, e assicurarsi che, quando trovano qualcosa, a una segnalazione in buona fede corrisponda una risposta in buona fede. La maggior parte delle segnalazioni è una transazione silenziosa: qualcuno trova un bug, noi lo correggiamo e tutti voltano pagina.
Ogni tanto, una di queste segnalazioni si trasforma in una storia davvero interessante. Questa è una di quelle.
Qualche settimana fa, un ricercatore esterno, Mehmet Ince, ci ha segnalato un bug di sicurezza della memoria in un'estensione Postgres inclusa nelle piattaforme Postgres gestite, tra cui Lakebase Postgres e Neon. Ciò che ha reso questo bug degno di nota non è solo il problema in sé. È quello che è successo intorno: come i nostri sistemi di rilevamento hanno intercettato i suoi test, con quanta rapidità siamo riusciti a proteggere i clienti e come la correzione definitiva sia tornata al suo posto d'origine. Nell'open source, a vantaggio di chiunque utilizzi la stessa estensione, non solo noi.
Se gestisci un team di sicurezza, operi su un'infrastruttura open source gestita o sei semplicemente curioso di sapere come si svolge un'interazione sana tra ricercatore e fornitore da entrambe le parti, questo articolo fa al caso tuo. Mehmet ha descritto la storia tecnica dettagliata dell'exploit sul suo blog. Qui vogliamo parlare della collaborazione.
| Il blog di Mehmet fa riferimento all'esposizione di dati tra clienti diversi su una piattaforma differente. Databricks esegue Lakebase Postgres e Neon su un'architettura microVM che fornisce un solido confine di sicurezza tra le istanze di calcolo. L'exploit di Mehmet non ha avuto alcun impatto sui clienti di Databricks. |
|---|
L'ecosistema delle estensioni di Postgres è uno dei principali fattori della sua popolarità e, sebbene il supporto vari a seconda del fornitore, i clienti si aspettano che i provider gestiti supportino le opzioni principali e di terze parti più diffuse. Una di queste è PostGIS, il toolkit geospaziale. All'interno di PostGIS si trova un'estensione più piccola e discreta chiamata address_standardizer che trasforma un indirizzo non strutturato come 123 Main St in una forma normalizzata.
Mehmet ha scoperto che address_standardizer presentava un classico difetto di sicurezza della memoria: un valore completamente controllato dal chiamante (parte di una "regola" grammaticale che il chiamante può fornire) veniva utilizzato per indicizzare un array interno a dimensione fissa senza un controllo dei limiti. Fornendo un valore fuori intervallo, si ottiene un accesso alla memoria fuori dai limiti.
La parte importante per un servizio Postgres gestito è chi può accedervi. address_standardizer fa parte del set di estensioni che un normale tenant può installare e utilizzare. Quindi non si trattava di un bug che richiedeva privilegi speciali per essere toccato. Un normale ruolo utente poteva chiamare la funzione e raggiungere il percorso di codice vulnerabile. È proprio questa caratteristica che trasforma un bug silenzioso e facile da trascurare in qualcosa che un team di piattaforma deve prendere sul serio.
Qui manteniamo deliberatamente i dettagli dell'exploit sul vago. L'analisi approfondita di Mehmet illustra la primitiva in modo dettagliato, e lo fa meglio di quanto farebbe un riassunto.
Di Mehmet D. Ince
La storia non è iniziata come una ricerca di vulnerabilità. Questa primavera, durante una riunione interna, il mio team ha chiesto se potessimo migrare alcune delle nostre istanze PostgreSQL verso un provider gestito. In qualità di CTO di PRODAFT, un'azienda europea di threat intelligence con circa 50 ingegneri, una delle mie responsabilità è garantire ai nostri clienti i servizi più sicuri possibili.
Gestivamo PostgreSQL direttamente da oltre un decennio, ma non avevo mai esaminato a fondo come i provider di Postgres gestito offrissero questi servizi dal punto di vista della sicurezza. Mi occupo di ricerca sulle vulnerabilità dai primi anni 2000, quindi mi concedo sempre una piccola finestra temporale per fare ricerche di sicurezza e comprendere meglio il rischio che corriamo semplicemente aggiungendo un'altra tecnologia al nostro stack. Come c'era da aspettarsi, le mie "rapide verifiche" tendono a concludersi con una segnalazione di vulnerabilità critica nella casella di posta di qualcuno. Certe abitudini sono difficili da perdere.
Dopo pochi giorni di ricerca, mi sono reso conto che quasi tutti i provider offrono all'incircica le stesse estensioni Postgres. Una vulnerabilità di corruzione della memoria in un'estensione ampiamente distribuita è a tutti gli effetti una vulnerabilità di corruzione della memoria in PostgreSQL stesso. Così ho scelto come target un'estensione chiamata address_standardizer, una piccola estensione di PostGIS disponibile praticamente ovunque.
Un lunedì sera, verso le 19:00 qui a Londra, Aaron mi ha inviato un'e-mail del tutto inaspettata, chiedendomi se l'attività che aveva attivato gli allarmi di produzione di Neon fosse mia. Stavo lavorando al porting del mio exploit funzionante su istanze Neon PostgreSQL per vedere se un singolo, semplice bug in una piccola e innocente estensione potesse davvero aprire la strada a un'escalation di privilegi. Avevo un PoC funzionante, ma gli ho inviato solo uno screenshot. Quel singolo screenshot è stato sufficiente per fargli avviare le contromisure!
Mi occupo di divulgazione responsabile delle vulnerabilità ai fornitori da oltre vent'anni e, anche dopo tutto questo tempo, è ancora difficile spiegare l'impatto e i rischi dei risultati senza perdere molto tempo a cercare il contatto giusto con cui parlare. Devo dire, tanto di cappello ad Aaron e al team di sicurezza di Databricks per aver contattato proattivamente i ricercatori in questo modo e per aver agito così rapidamente!
Vedi il post di Mehmet per ulteriori informazioni.
Dal nostro punto di vista, questo è un caso di studio su come la divulgazione coordinata dovrebbe funzionare.
Mehmet ha condiviso la sua prova e, entro la fine della giornata, la segnalazione è arrivata alle persone giuste, con i nostri ingegneri della sicurezza che l'hanno convalidata rispetto all'esatta versione di PostGIS distribuita da Neon. Abbiamo confermato che il percorso di codice vulnerabile era raggiungibile da un normale ruolo tenant e lo abbiamo trattato di conseguenza.
Fin dall'inizio abbiamo preso una decisione deliberata che riteniamo valga la pena spiegare, perché è una questione che ogni team di piattaforma prima o poi si trova ad affrontare: un bug in un componente open source che distribuisci è comunque un tuo problema. La causa principale risiedeva a monte in PostGIS, ma l'esposizione era nostra. Abbiamo messo quell'estensione a disposizione dei tenant per impostazione predefinita, quindi l'impatto era di nostra responsabilità. Non l'abbiamo liquidata come una questione di "terze parti". Al contrario, abbiamo accettato la segnalazione, gestito la risposta e premiato il ricercatore che l'ha sollevata.
Inoltre, non volevamo essere vincolati ai tempi di rilascio a monte mentre i clienti erano esposti. Il nostro sistema di compilazione delle estensioni è progettato intenzionalmente in modo da poter applicare un set arbitrario di patch a qualsiasi estensione Postgres a monte prima di compilarla e pacchettizzarla, sia che si tratti di retroportare una correzione o di disabilitare un percorso di codice rischioso nella nostra build. Poiché questo set di patch risiede a valle anziché nel codice sorgente a monte, possiamo agire indipendentemente da quando quest'ultimo rilascia una nuova versione. In questo modo siamo riusciti ad agire rapidamente per proteggere i clienti e a lavorare in parallelo per correggere l'ecosistema in modo adeguato.
La creazione di una correzione duratura ha richiesto un paio di iterazioni. Il primo tentativo non copriva tutti i casi e preferiamo prenderci una settimana in più e fare le cose per bene piuttosto che rilasciare una soluzione parziale. La correzione consolidata è stata distribuita per proteggere i tenant di Neon e Lakebase, che non hanno dovuto intraprendere alcuna azione.
Ecco dove la cosa si fa interessante, e anche un po' fortunata.
La correzione canonica spettava a PostGIS. È il loro codice, il loro rilascio, la loro decisione. Databricks ringrazia i manutentori di PostGIS, che mantengono in funzione un elemento fondamentale del mondo geospaziale lavorando in gran parte come volontari. Mehmet la pensava chiaramente allo stesso modo e ha agito di conseguenza: ha donato la sua ricompensa al progetto PostGIS e ha raddoppiato la cifra di tasca propria, destinando il premio direttamente all'impegno dei volontari sul cui codice si basa l'intero settore del Postgres gestito. Il nostro piano era semplice: proteggere prima i nostri clienti, poi collaborare con Mehmet per risolvere la causa principale a monte, in modo che chiunque utilizzi address_standardizer possa trarne vantaggio, non solo Neon.
Poi una coincidenza ha complicato le cose. Più o meno nello stesso periodo, il bug sottostante è stato corretto a monte, come una piccola correzione di un memory leak, senza un CVE e senza troppi clamori.
La correzione upstream, a quanto pare, non copriva tutti i casi. Mehmet ha verificato esattamente dove questa fosse insufficiente e ha inviato le parti rimanenti di nuovo upstream, colmando la lacuna per l'intera community. Nessun CVE è stato assegnato per la catena, il che rappresenta una piccola lezione su quanto sia facile che una correzione significativa per la sicurezza della memoria passi inosservata in una nota di rilascio come un "minore" intervento di pulizia.
La conclusione che ci interessa: il ricercatore ha potuto fare la cosa giusta con la causa principale, l'upstream ha ottenuto una correzione completa e i nostri clienti erano già protetti mentre tutto questo accadeva.
Se gestisci un servizio gestito basato su componenti open source (un database gestito, o qualsiasi altra cosa gestita), la scomoda verità in questa storia è che la tua superficie di attacco include codice che non hai scritto e un modello di minaccia che i suoi autori potrebbero non aver mai previsto. Una piccola, popolare e silenziosa estensione è esattamente il tipo di cosa facile da distribuire e facile da dimenticare.
Alcune cose che hanno funzionato per noi, e che potrebbero funzionare anche per te:
Se sei un ricercatore di sicurezza, ci farebbe davvero piacere sentirti. Soprattutto quando puoi dimostrare un impatto reale e misurabile sulla piattaforma, come ha fatto Mehmet. Invia una segnalazione tramite hackerone.com/databricks.
Grazie a Mehmet Ince per una segnalazione ben documentata e in buona fede, e per aver fatto la cosa giusta con la causa principale upstream. Grazie ai manutentori di PostGIS, il cui lavoro open source è una parte enorme del mondo geospaziale che dipende da esso. E grazie agli ingegneri di Neon e Lakebase che hanno trasformato rapidamente e con calma una segnalazione in una correzione distribuita.
A tutti i ricercatori che lavorano con noi per rendere la piattaforma più sicura: vi vediamo e vi siamo grati. Ci vediamo su HackerOne.
(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale
Iscriviti al nostro blog e ricevi gli ultimi articoli direttamente nella tua casella di posta.