Un caso de estudio de divulgación de Lakebase Postgres
por Aaron Kobayashi, Mehmet D. Ince, Anurag Srivastava y Alexey Kondratov
Algunas de nuestras mejores inversiones en seguridad no han sido herramientas o escáneres. Han sido en relaciones. Databricks gestiona un programa de recompensas por errores (bug bounty) porque la forma más rápida de encontrar los puntos débiles de una plataforma es permitir que personas con talento y curiosidad los busquen, y asegurarse de que, cuando encuentren algo, un informe de buena fe reciba una respuesta de buena fe. La mayoría de los informes son una transacción silenciosa: alguien encuentra un error, lo solucionamos y todos siguen adelante.
De vez en cuando, uno de ellos se convierte en una historia realmente buena. Esta es una de esas.
Hace unas semanas, un investigador externo, Mehmet Ince, nos mostró un error de seguridad de memoria en una extensión de Postgres que se incluye en plataformas administradas de Postgres, como Lakebase Postgres y Neon. Lo que hizo que valiera la pena escribir sobre esto no es solo el error. Es lo que pasó a su alrededor: cómo nuestra detección capturó sus pruebas, qué tan rápido pudimos proteger a los clientes y cómo la solución real terminó de vuelta donde correspondía. En el código abierto (open source), para todos los que ejecutan la misma extensión, no solo para nosotros.
Si diriges un equipo de seguridad, operas infraestructura administrada de código abierto o simplemente tienes curiosidad por ver cómo es una interacción saludable entre investigador y proveedor desde ambos lados, esto es para ti. Mehmet ha escrito la historia detallada de la explotación técnica en su propio blog. Aquí, queremos hablar sobre la colaboración.
| El blog de Mehmet hace referencia a la exposición de datos entre clientes en una plataforma diferente. Databricks ejecuta Lakebase Postgres y Neon en una arquitectura de microVM que proporciona un límite de seguridad sólido entre las instancias de cómputo. El exploit de Mehmet no tuvo ningún impacto entre clientes en Databricks. |
|---|
El ecosistema de extensiones de Postgres es uno de los principales motores de su popularidad y, aunque el soporte varía según el proveedor, los clientes esperan que los proveedores administrados admitan las opciones principales y de terceros más utilizadas. Una de ellas es PostGIS, el conjunto de herramientas geoespaciales. Dentro de PostGIS hay una extensión más pequeña y sencilla llamada address_standardizer que convierte una dirección no estructurada como 123 Main St en un formato normalizado.
Mehmet descubrió que address_standardizer tenía un fallo clásico de seguridad de memoria: un valor que el llamador controla por completo (parte de una "regla" gramatical que el llamador puede proporcionar) se utilizaba para indexar en una matriz interna de tamaño fijo sin una comprobación de límites. Si se le proporciona un valor fuera de rango, se produce un acceso a la memoria fuera de los límites.
La parte importante para un servicio de Postgres administrado es quién puede acceder a él. address_standardizer está en el conjunto de extensiones que un usuario normal puede instalar y usar. Por lo tanto, este no era un error que requiriera privilegios especiales para activarse. Un rol de cliente común podría llamar a la función y llegar a la ruta de código vulnerable. Esa es exactamente la propiedad que convierte un error silencioso y fácil de pasar por alto en algo que un equipo de plataforma debe tomar en serio.
Estamos manteniendo deliberadamente los detalles de la explotación de forma superficial aquí. El análisis profundo de Mehmet detalla el proceso correctamente, y lo hace mejor de lo que lo haría un resumen.
Por Mehmet D. Ince
La historia no comenzó como una investigación de vulnerabilidades. Esta primavera, durante una reunión interna, mi equipo preguntó si podíamos migrar algunas de nuestras instancias de PostgreSQL a un proveedor administrado. Como CTO de PRODAFT, una empresa europea de inteligencia de amenazas con unos 50 ingenieros, una de mis responsabilidades es garantizar que ofrezcamos los servicios más seguros posibles a nuestros clientes.
Habíamos estado ejecutando PostgreSQL nosotros mismos durante más de una década, pero nunca había revisado adecuadamente cómo los proveedores de Postgres administrado ofrecían estos servicios desde una perspectiva de seguridad. He estado investigando vulnerabilidades desde principios de la década de 2000, por lo que siempre me doy un pequeño margen para realizar algunas investigaciones de seguridad y comprender mejor el riesgo que asumimos simplemente al agregar otra tecnología a nuestra infraestructura. Como era de esperar, mis "revisiones rápidas" suelen terminar con un informe de vulnerabilidad crítica en la bandeja de entrada de alguien. Algunos hábitos son difíciles de dejar atrás.
A los pocos días de mi investigación, me di cuenta de que casi todos los proveedores incluyen prácticamente las mismas extensiones de Postgres. Una vulnerabilidad de corrupción de memoria en una extensión ampliamente implementada es, de hecho, una vulnerabilidad de corrupción de memoria en el propio PostgreSQL. Así que elegí como objetivo una extensión llamada address_standardizer, una pequeña extensión de PostGIS disponible literalmente en todas partes.
Un lunes por la tarde, alrededor de las 7 p.m. aquí en Londres, Aaron me envió un correo electrónico bastante inesperado, preguntándome si la actividad que activó las alarmas de producción de Neon me pertenecía. Estaba trabajando en adaptar mi exploit para que funcionara en instancias de Neon PostgreSQL para ver si un único y simple error en una pequeña e inocente extensión realmente podía exponer una ruta de escalada de privilegios allí. Tenía una PoC funcional, pero solo le envié una captura de pantalla. ¡Esa única captura de pantalla fue suficiente para que comenzara a tomar medidas!
He estado divulgando vulnerabilidades de manera responsable a los proveedores durante más de dos décadas y, incluso después de todos estos años, todavía es difícil explicar el impacto y los riesgos de los hallazgos sin pasar mucho tiempo buscando el contacto adecuado para hablar. Debo decir, ¡felicitaciones a Aaron y al equipo de seguridad de Databricks por comunicarse proactivamente con investigadores de esta manera y tomar medidas tan rápidas!
Consulta la publicación de Mehmet para obtener más información.
Desde nuestro lado de la mesa, este es un caso de estudio sobre cómo la divulgación coordinada funciona de la manera en que se supone que debe hacerlo.
Mehmet compartió su prueba y, al final del día, el informe ya había circulado entre las personas adecuadas, y nuestros ingenieros de seguridad lo validaron con la versión exacta de PostGIS que incluye Neon. Confirmamos que la ruta de código vulnerable era accesible para un rol de usuario normal y la tratamos en consecuencia.
Desde el principio, tomamos una decisión deliberada que creemos que vale la pena explicar, porque es una pregunta a la que todo equipo de plataforma se enfrenta tarde o temprano: un error en un componente de código abierto que distribuyes sigue siendo tu problema. La causa raíz estaba en el proyecto original (upstream) de PostGIS, pero la exposición era nuestra. Pusimos esa extensión a disposición de los usuarios de forma predeterminada, por lo que el impacto era nuestra responsabilidad. No lo descartamos como algo de "terceros". En su lugar, aceptamos el informe, gestionamos la respuesta y recompensamos al investigador que lo presentó.
Tampoco estábamos dispuestos a depender del calendario de lanzamientos del proyecto original mientras los clientes estuvieran expuestos. Nuestro sistema de compilación de extensiones está diseñado intencionalmente para que podamos aplicar un conjunto arbitrario de parches sobre cualquier extensión de Postgres original antes de compilarla y empaquetarla, ya sea para adaptar una solución anterior o deshabilitar una ruta de código riesgosa en nuestra propia compilación. Debido a que ese conjunto de parches reside en nuestra distribución (downstream) en lugar de en el código fuente original, podemos actuar independientemente de cuándo el proyecto original publique una versión. Así, pudimos actuar rápidamente para proteger a los clientes y trabajar en paralelo para solucionar el ecosistema de manera adecuada.
Crear la solución definitiva tomó un par de iteraciones. La primera versión no cubría todos los casos, y preferimos tomarnos una semana adicional para hacerlo bien antes que lanzar algo incompleto. La solución reforzada se implementó para proteger a los usuarios de Neon y Lakebase, quienes no necesitaron realizar ninguna acción por su parte.
Aquí es donde se pone interesante, y un poco afortunado.
La solución canónica correspondía a PostGIS. Es su código, su lanzamiento, su decisión. Databricks agradece a los mantenedores de PostGIS, quienes mantienen en funcionamiento una pieza fundamental del mundo geoespacial en gran medida de forma voluntaria. Mehmet claramente sintió lo mismo e hizo algo al respecto: donó su recompensa al proyecto PostGIS y la igualó de su propio bolsillo, destinando la recompensa directamente al esfuerzo voluntario en cuyo código se apoya toda la industria de Postgres administrado. Nuestro plan era sencillo: proteger primero a nuestros clientes y luego trabajar con Mehmet para solucionar la causa raíz en el proyecto original para que todos los que ejecutan address_standardizer se beneficien, no solo Neon.
Luego, una coincidencia complicó las cosas. Casi al mismo tiempo, el error subyacente se corrigió en el proyecto original como una pequeña solución para una fuga de memoria, sin un CVE y sin bombos ni platillos.
Resultó que la corrección upstream no cubría todos los casos. Mehmet validó exactamente dónde fallaba y envió las partes restantes de vuelta a upstream, cerrando la brecha para toda la comunidad. No se asignó ningún CVE para la cadena, lo cual es una pequeña lección sobre lo fácil que es que una corrección importante de seguridad de memoria pase desapercibida en una nota de versión como una limpieza "menor".
La conclusión que nos importa: el investigador pudo hacer lo correcto con la causa raíz, upstream obtuvo una corrección completa y nuestros clientes ya estaban protegidos mientras todo eso sucedía.
Si operas un servicio gestionado basado en componentes de código abierto (una base de datos gestionada, cualquier cosa gestionada), la incómoda verdad en esta historia es que tu superficie de ataque incluye código que no escribiste y un modelo de amenazas que sus autores tal vez nunca contemplaron. Una extensión pequeña, popular y poco activa es exactamente el tipo de cosas que es fácil de lanzar y fácil de olvidar.
Algunas cosas que nos funcionaron y que podrían funcionarte a ti:
Si eres un investigador de seguridad, realmente nos gustaría saber de ti. Especialmente cuando puedas demostrar un impacto real y medible en la plataforma, como lo hizo Mehmet. Envía tu informe a través de hackerone.com/databricks.
Gracias a Mehmet Ince por un informe bien documentado y de buena fe, y por hacer lo correcto con la causa raíz en upstream. Gracias a los mantenedores de PostGIS, cuyo trabajo de código abierto es una parte fundamental del mundo geoespacial que depende de él. Y gracias a los ingenieros de Neon y Lakebase que, de manera rápida y tranquila, convirtieron un informe en una corrección implementada.
A todos los investigadores que trabajan con nosotros para hacer que la plataforma sea más segura: los vemos y estamos agradecidos. Nos vemos en HackerOne.
(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original
Suscríbete a nuestro blog y recibe las últimas publicaciones directamente en tu bandeja de entrada.