De la base de datos a Linux: PostgreSQL permitió eludir la protección de Snowflake con herramientas nativas

Un servicio en la nube puede prohibir comandos peligrosos, pero dejar una ruta alternativa mediante las funciones normales de la base de datos. El equipo Varonis Threat Labs detectó en Snowflake Postgres una cadena de acciones que permitía elevar privilegios y ejecutar comandos del sistema operativo en el servidor PostgreSQL. Snowflake solucionó el problema antes de la publicación del análisis técnico.

La cadena vulnerable empezaba con el rol snowflake_admin, que no tenía estatus de superusuario, pero sí el permiso CREATEROLE. Los evaluadores se asignaron los roles de sistema pg_read_all_data y pg_write_all_data, obteniendo acceso para leer y modificar tablas en toda la instancia de PostgreSQL. Para el ataque se requerían privilegios en la base; el acceso de red por sí solo no bastaba.

El siguiente eslabón fue el programador pg_cron. El equipo modificó la entrada del trabajo de mantenimiento para que PostgreSQL ejecutara código SQL en nombre de postgres mediante una conexión local sin comprobación de contraseña. El trabajo creó una función SECURITY DEFINER con privilegios de superusuario y abrió el camino hacia el rol snowflake_superuser. La prohibición de asignar directamente el estatus de superusuario no funcionó.

Incluso los privilegios de superusuario no daban acceso directo al sistema operativo. Snowflake había bloqueado de antemano COPY TO PROGRAM, ALTER SYSTEM y las funciones de lectura de archivos. Sin embargo, mediante LANGUAGE internal fue posible registrar nuevas funciones SQL vinculadas a funciones internas ya existentes de PostgreSQL. Así, los evaluadores recuperaron la capacidad de leer y escribir archivos bajo otros nombres.

Durante la comprobación, el equipo leyó archivos del sistema, el certificado mTLS interno con la clave privada y las credenciales temporales de AWS STS que estaban almacenadas en claro. Después, el mecanismo lo_export permitió sobrescribir postgresql.auto.conf y sustituir el parámetro archive_command. PostgreSQL ejecuta el comando indicado mediante la shell de Linux al archivar el WAL, el registro que guarda los cambios de la base.

Como resultado, los comandos se ejecutaron desde la cuenta del sistema postgres dentro de la máquina virtual dedicada. El acceso podía permitir modificar o eliminar archivos de la base, dificultar la recuperación y dejar parte de las acciones fuera de la auditoría SQL habitual. La demostración se limitó a una instancia aislada propia; no se ha confirmado acceso a entornos de clientes ajenos.

Para PostgreSQL, una transición similar desde privilegios de servicio hasta código del sistema operativo no es la primera vez. En septiembre se informó de la vulnerabilidad de replicación que permitía cargar código nativo mediante la decodificación lógica. El nuevo escenario se diferencia en que utiliza una cadena de funcionalidades estándar y elude las limitaciones del proveedor sin desactivar directamente los mecanismos de protección.

Varonis entregó los detalles a Snowflake el 31 de mayo de 2026. La compañía confirmó el problema el 9 de junio y el 17 de octubre presentó los resultados en BSides NYC. Las correcciones se aplicaron del lado del servicio antes de la divulgación, por lo que los clientes no necesitan parches. Varonis recomienda restringir el permiso CREATEROLE, no asignar snowflake_admin a servicios de aplicación y bloquear el acceso a las bases mediante reglas de red.