Audit che si auto-sconfiggono: laboratorio riproducibile che mostra un ruolo PostgreSQL a bassi privilegi che acceca reversibilmente un auditor basato su trigger + avvelenamento dell'attribuzione (PG14/16), con difese. Dati sintetici; citate le primitive di CVE-2018-1058.

Richiede Docker. Utilizza le immagini -alpine (motore funzionalmente identico).

Cross-engine (famiglia MySQL + SQL Server)

Lo studio è riprodotto su altre due famiglie di motori. Famiglia MySQL (MariaDB, modello a trigger DEFINER) in scripts/mysql/:

SQL Server (modello ownership-chaining) in scripts/mssql/ — viene eseguito su un'istanza LocalDB locale tramite sqlcmd dell'host (niente Docker; l'attaccante a bassi privilegi è modellato con l'impersonificazione EXECUTE AS USER):

Avvertenza sulla riproducibilità (SQL Server). A differenza dei motori Docker, il terzo motore SQL Server ha una dipendenza dall'host: viene eseguito su un'istanza locale di SQL Server LocalDB tramite sqlcmd (percorso hardcoded in run_matrix_mssql.sh), quindi è solo Windows e non può essere ancorato a un digest di immagine. L'attaccante a bassi privilegi è modellato con l'impersonificazione EXECUTE AS USER (LocalDB supporta solo l'autenticazione Windows). I risultati sul comportamento del motore (DISABLE a residuo zero; la guardia DDL non intercetta DISABLE) sono indipendenti dal tipo di sessione e varrebbero per un login reale; i risultati sui privilegi sugli oggetti sono applicati fedelmente dall'impersonificazione. È il meno portabile dei tre motori — detto onestamente.

Risultato principale cross-engine: la classe shadow di search_path (1A/1B) non si trasferisce né a MySQL né a SQL Server (niente search_path), ma la sostituzione del trigger, il bypass dormiente e l'avvelenamento dell'attribuzione sì. Il binding dei privilegi DEFINER di MySQL rende l'accecamento più rilevabile; SQL Server, come PostgreSQL, consente un ripristino byte-perfetto e aggiunge una primitiva DISABLE TRIGGER a residuo zero che la sua stessa difesa DDL non intercetta. Confronto completo dei tre motori in FINDINGS.md.

Struttura

Risultato principale

• 1A piantare uno shadow in uno schema nuovo — fallisce in fase di setup (un ruolo appena creato non può fare CREATE SCHEMA), non perché "pg_catalog vince". Piantarlo nel già scrivibile public fa shadow: 1S (stessa firma, ordinamento per schema) e 1T (l'overload esatto batte il built-in anche con pg_catalog per primo — isola la specificità di tipo) entrambi accecano (payload azzerato).
• 1B overload esatto di row_to_json con tipo composito — acceca l'auditor quando public è scrivibile e il search_path del trigger non è fissato. Raggiungibile su PostgreSQL standard ≤14; condizionato da una cattiva configurazione su 15+. Fissare il search_path lo neutralizza ovunque.
• 1C sostituire una funzione di audit di proprietà dell'app — acceca ed è reversibile con un object-diff pulito (replay verbatim della sorgente) — ma un canary scrittura-vs-audit e un event trigger DDL lo intercettano comunque.
• La dormienza controllata da GUC e l'avvelenamento dell'attribuzione in-database funzionano entrambi sotto le loro precondizioni (di cattiva configurazione); la riga di audit fabbricata è indistinguibile dalla sola tabella di audit.
• Il logging a livello di motore (pgaudit/log_statement) + il sink con hash a catena sono le difese che chiudono l'insieme.

Postura di divulgazione responsabile

Riprodotto su PostgreSQL standard in un laboratorio locale con dati anonimizzati/sintetici. L'SQL degli attacchi è limitato allo schema di laboratorio costruito qui; questo è uno studio di fattibilità/difesa, non un payload weaponizzato. Le primitive sottostanti sono già pubbliche (CVE-2018-1058; escalation del search_path di SECURITY DEFINER) — il contributo è la composizione e la valutazione delle difese. Nessun sistema reale è identificato.