Auditorías Autoderrotantes: laboratorio reproducible que muestra un rol de PostgreSQL con bajos privilegios cegando reversiblemente a un auditor basado en disparadores + envenenando la atribución (PG14/16), con defensas. Datos sintéticos; se citan primitivas de CVE-2018-1058.

Requiere Docker. Utiliza las imágenes -alpine (motor funcionalmente idéntico).

Multi-motor (familia MySQL + SQL Server)

El estudio se reproduce en dos familias de motores más. Familia MySQL (MariaDB, modelo de disparador DEFINER) en scripts/mysql/:

SQL Server (modelo de encadenamiento de propiedad) en scripts/mssql/ — se ejecuta en una instancia LocalDB local mediante sqlcmd del host (sin Docker; el atacante de bajos privilegios se modela con suplantación EXECUTE AS USER):

Advertencia de reproducibilidad (SQL Server). A diferencia de los motores Docker, el tercer motor, SQL Server, tiene una dependencia del host: se ejecuta en una instancia local de SQL Server LocalDB mediante sqlcmd (ruta fijada en run_matrix_mssql.sh), por lo que solo funciona en Windows y no puede fijarse a un digest de imagen. El atacante de bajos privilegios se modela con suplantación EXECUTE AS USER (LocalDB solo admite autenticación de Windows). Los hallazgos sobre el comportamiento del motor (DISABLE sin residuos; el guard de DDL no detecta DISABLE) son independientes del tipo de sesión y se mantendrían para un login real; los hallazgos sobre concesiones de objetos se aplican fielmente mediante la suplantación. Es el menos portable de los tres motores — se señala con honestidad.

Resultado principal entre motores: la clase de sombra search_path (1A/1B) no se traslada ni a MySQL ni a SQL Server (no existe search_path), pero la sustitución de disparadores, la evasión latente y el envenenamiento de atribución sí se trasladan. El enlace de privilegios DEFINER de MySQL hace que el cegado sea más detectable; SQL Server, como PostgreSQL, permite una restauración perfecta byte a byte y añade una primitiva DISABLE TRIGGER sin residuos que su propia defensa DDL no detecta. Comparación completa de los tres motores en FINDINGS.md.

Estructura

Resultado principal

• 1A plantar una sombra en un esquema nuevo — falla en la configuración (un rol recién creado no puede ejecutar CREATE SCHEMA), no porque "pg_catalog gana". Plantar en public, que ya es escribible, sí genera sombra: 1S (misma firma, orden de esquemas) y 1T (la sobrecarga exacta vence a la función integrada incluso con pg_catalog primero — aísla la especificidad de tipo) ambas ciegan (payload anulado).
• 1B sobrecarga exacta de tipo compuesto de row_to_json — ciega al auditor cuando public es escribible y el search_path del disparador no está fijado. Alcanzable en PostgreSQL estándar ≤14; en 15+ requiere una mala configuración. Fijar search_path lo neutraliza en todos los casos.
• 1C reemplazar una función de auditoría propiedad de la aplicación — ciega y es reversible con un diff de objetos limpio (reproducción verbatim de la fuente) — pero un canario de escritura-vs-auditoría y un disparador de eventos DDL siguen detectándolo.
• El estado latente controlado por GUC y el envenenamiento de atribución dentro de la base de datos funcionan ambos bajo sus precondiciones (de mala configuración); la fila de auditoría fabricada es indistinguible considerando únicamente la tabla de auditoría.
• El registro a nivel de motor (pgaudit/log_statement) + el sumidero encadenado por hash son las defensas que cierran el conjunto.

Postura de divulgación responsable

Reproducido en PostgreSQL estándar en un laboratorio local con datos anonimizados/sintéticos. El SQL de ataque está limitado al esquema de laboratorio construido aquí; se trata de un estudio de viabilidad/defensa, no de un payload armado. Las primitivas subyacentes ya son públicas (CVE-2018-1058; escalada de search_path en SECURITY DEFINER) — la contribución es la composición y la evaluación de defensas. No se identifica ningún sistema real.