El límite "gestionado" no era un muro
Los proveedores de PostgreSQL gestionado como Supabase, Neon y Amazon Aurora ofrecen a los clientes roles administrativos potentes, pero retienen los privilegios reales de superuser. Su objetivo es ofrecer un entorno seguro y multiusuario donde los usuarios controlen su base de datos sin afectar al host subyacente ni a otros clientes.
Los proveedores logran esto mediante el despliegue de extensiones o hooks personalizados. Estas capas interceptan y bloquean operaciones potencialmente peligrosas, especialmente aquellas que involucran el sistema de archivos, incluso desde los roles de cara al cliente con mayores privilegios. Por ejemplo, un proveedor podría bloquear lo_export, una función nativa de PostgreSQL diseñada para escribir objetos grandes en el disco del servidor.
Esta capa de restricción personalizada, sin embargo, puede crear una falsa sensación de seguridad. Si la barrera de seguridad comprueba solo el nombre de un comando en lugar de su funcionalidad subyacente, un usuario puede eludir el bloqueo. Volver a registrar el mismo alias de función interna de C bajo un nuevo nombre no monitoreado evita la lista de bloqueo, permitiendo la invocación de una funcionalidad que de otro modo estaría restringida. Este descuido fundamental formó la base de una vulnerabilidad significativa.
Un nuevo nombre se deslizó a través del filtro
La vulnerabilidad reportada explotó un punto ciego crítico en el filtrado basado en nombres. La función lo_export de PostgreSQL escribe objetos grandes de la base de datos directamente en los archivos del servidor. Los proveedores gestionados, al reconocer este peligro, normalmente bloquean lo_export por nombre, evitando su ejecución incluso para roles de cliente potentes.
Un investigador de seguridad demostró cómo eludir esta barrera de seguridad. Recrearon el acceso a la rutina interna subyacente utilizando el mecanismo LANGUAGE internal de PostgreSQL. Esto les permitió definir una nueva función con un nombre no monitoreado que apuntaba exactamente a la misma implementación de C en el backend que la función bloqueada lo_export.
Esta técnica clonó efectivamente la capacidad peligrosa bajo una etiqueta diferente, eludiendo la extensión de seguridad del proveedor. Una vez que esta función con alias estuvo disponible, el investigador pudo escribir archivos arbitrarios en el disco del servidor de la base de datos.
Esta vulnerabilidad destaca una debilidad fundamental en los modelos de seguridad que dependen únicamente del filtrado basado en nombres. Los nombres alternativos pueden apuntar a la misma implementación subyacente, lo que significa que verificar solo la etiqueta no equivale a controlar la capacidad. Las extensiones de los proveedores bloquearon la palabra "lo_export" pero no la acción de escribir archivos en el servidor, dejando expuesto un fallo de diseño crítico.
De permisos SQL a código a nivel de host
La función lo_export replicada, operando ahora bajo un alias no bloqueado, proporcionó una primitiva crítica: la capacidad de escribir archivos arbitrarios en el host de PostgreSQL. Los atacantes aprovecharon esto para colocar una biblioteca compartida compilada (archivo .so) en el disco del servidor.
Con la biblioteca maliciosa en su lugar, el siguiente paso consistió en registrarla como una función de lenguaje C de PostgreSQL. Esto se logra mediante CREATE FUNCTION ... LANGUAGE C, que instruye a PostgreSQL para cargar y exponer una función específica de la biblioteca compartida directamente en el entorno SQL de la base de datos.
Cuando un atacante invocaba esta función de lenguaje C recién registrada a través de una simple consulta SQL, la base de datos ejecutaba su código arbitrario. Fundamentalmente, este código se ejecutaba con los permisos del sistema operativo del propio proceso de PostgreSQL en el host de la base de datos. Esto no es acceso root, ni otorga automáticamente acceso a los datos de otros clientes, ya que las instancias suelen estar aisladas.
Sin embargo, la ejecución en el host proporciona un punto de apoyo significativo. Permite la persistencia en el servidor, facilita una enumeración exhaustiva del sistema y puede facilitar intentos de movimiento lateral dentro de la infraestructura del proveedor. La gravedad depende en gran medida de los mecanismos de aislamiento específicos y las configuraciones de red de cada servicio gestionado. Para un desglose técnico detallado, consulte Breaking the PostgreSQL Superuser Guardrails: Attacking Security-Hardening Extensions.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
Los proveedores deben asegurar el límite que venden
Supabase respondió rápidamente, informando parches para cuatro problemas críticos. Otros proveedores ofrecieron respuestas públicas más lentas o poco claras, mientras que el equipo central de PostgreSQL atribuyó la responsabilidad directamente a los proveedores de servicios, afirmando que el modelo de seguridad de PostgreSQL asume que el superuser controla las funciones internas.
Los lectores que busquen una visión más profunda deben consultar la investigación fundamental de Mehmet Ince, “Breaking the PostgreSQL Superuser Guardrails”. El proyecto supautils también proporciona una referencia crítica, junto con la documentación detallada de Supabase sobre roles y operaciones no admitidas, que ahora reflejan estas lecciones.
Este incidente ofrece una lección clara para los proveedores. Bloquear operaciones peligrosas por nombre resulta insuficiente. Una seguridad robusta exige: - controles estrictos sobre los enlaces internos y de lenguaje C - permisos de catálogo meticulosos - un aislamiento más fuerte a nivel de sistema operativo
Estas medidas, y no simplemente listas de bloqueo más largas, son esenciales para asegurar el límite gestionado que venden. La integridad de PostgreSQL en la nube depende de que los proveedores hagan cumplir los límites que prometen.
Preguntas frecuentes
¿Cuál fue la vulnerabilidad de PostgreSQL gestionado?
Un investigador eludió las restricciones del proveedor registrando una función interna peligrosa de PostgreSQL bajo un nombre que los filtros de los proveedores no bloqueaban.
¿Expuso la falla el contenido de la base de datos de otros clientes?
No automáticamente. La escalada demostrada proporcionó ejecución de código como el usuario del sistema operativo PostgreSQL en el host de la base de datos, creando un punto de apoyo en lugar de acceso instantáneo a los datos de otros inquilinos.
¿Fue esto una vulnerabilidad del núcleo de PostgreSQL?
El equipo de seguridad de PostgreSQL lo caracterizó como un problema del lado del proveedor: los servicios gestionados deben hacer cumplir de forma segura los límites de privilegios que imponen.
¿Qué deberían cambiar los proveedores de PostgreSQL gestionado?
Deberían restringir los enlaces peligrosos de funciones internas y de lenguaje C, endurecer los permisos de catálogo y aislar los procesos de la base de datos a nivel de sistema operativo.