Auditorias Autodestrutivas: laboratório reproduzível que demonstra uma role PostgreSQL de baixo privilégio cegando reversivelmente um auditor baseado em triggers + envenenamento de atribuição (PG14/16), com defesas. Dados sintéticos; primitivas do CVE-2018-1058 citadas.

Requer Docker. Usa as imagens -alpine (motor funcionalmente idêntico).

Entre motores (família MySQL + SQL Server)

O estudo é reproduzido em mais duas famílias de motores. Família MySQL (MariaDB, modelo de trigger DEFINER) em scripts/mysql/:

SQL Server (modelo de encadeamento de propriedade) em scripts/mssql/ — executa em uma instância LocalDB local via sqlcmd do host (sem Docker; o atacante de baixo privilégio é modelado com personificação EXECUTE AS USER):

Ressalva de reprodutibilidade (SQL Server). Ao contrário dos motores Docker, o terceiro motor (SQL Server) tem uma dependência do host: ele executa em uma instância local SQL Server LocalDB via sqlcmd (caminho embutido no código em run_matrix_mssql.sh), portanto é exclusivo para Windows e não pode ser fixado a um digest de imagem. O atacante com privilégios mínimos é modelado com personificação EXECUTE AS USER (LocalDB só aceita autenticação Windows). Os achados de comportamento do motor (DISABLE de zero resíduo; a guarda de DDL não detecta DISABLE) são independentes do tipo de sessão e valeriam para um login real; os achados sobre concessões de objeto são aplicados fielmente pela personificação. É o menos portátil dos três motores — registrado com honestidade.

Resultado principal entre motores: a classe de sombreamento search_path (1A/1B) não se transfere nem para o MySQL nem para o SQL Server (não há search_path), mas substituição de trigger, bypass dormente e envenenamento de atribuição se transferem. A vinculação de privilégio DEFINER do MySQL torna o cegamento mais detectável; o SQL Server, assim como o PostgreSQL, permite restauração byte a byte e adiciona um primitivo DISABLE TRIGGER de zero resíduo que a própria defesa de DDL do motor não detecta. Comparação completa dos três motores em FINDINGS.md.

Estrutura

Resultado principal

• 1A plantar uma sombra em um schema novo — falha na configuração (uma role nova não pode CREATE SCHEMA), não porque "pg_catalog vence". Plantar no public já gravável de fato faz sombreamento: 1S (mesma assinatura, ordenação de schema) e 1T (sobrecarga exata vence a função nativa mesmo com pg_catalog em primeiro — isola a especificidade de tipo) ambos cegam (payload anulado).
• 1B sobrecarga exata de row_to_json para tipo composto — cega o auditor quando public é gravável e o search_path do trigger não está fixado. Atingível no PostgreSQL padrão ≤14; na 15+, exige má configuração. Fixar o search_path o derrota em qualquer cenário.
• 1C substituir uma função de auditoria de propriedade da aplicação — cega e é reversível com um object-diff limpo (replay literal do código-fonte) — mas um canário de escrita-vs-auditoria e um event trigger de DDL ainda o detectam.
• Adormecimento controlado por GUC e envenenamento de atribuição dentro do banco funcionam sob suas pré-condições (má configuração); a linha de auditoria fabricada é indistinguível considerando apenas a tabela de auditoria.
• Logging no nível do motor (pgaudit/log_statement) + sink encadeado por hash são as defesas que fecham o conjunto.

Postura de divulgação responsável

Reproduzido em PostgreSQL padrão em um laboratório local com dados anonimizados/sintéticos. O SQL de ataque está restrito ao schema de laboratório construído aqui; este é um estudo de viabilidade/defesa, não um payload ofensivo. Os primitivos subjacentes já são públicos (CVE-2018-1058; escalada de search_path via SECURITY DEFINER) — a contribuição é a composição e a avaliação de defesa. Nenhum sistema real é identificado.