Privilege Escalation in PostgreSQL 9.3-10

This repository is a defensive-security research lab, not a remote weaponized exploit kit. It contains 34 files, mostly Markdown documentation plus Bash and SQL used to build disposable PostgreSQL and MariaDB containers, instantiate a trigger-based audit victim, execute attack variants, and record results. The main code lives under scripts/ and scripts/mysql/. For PostgreSQL, scripts/10_victim.sql builds a lab database (labdb), app schema/table (app.accounts), audit schema/table (audit.logged_actions), and a SECURITY DEFINER trigger function audit.if_modified() that logs row changes via unqualified row_to_json(). scripts/20_attacks.sql implements the attack matrix: 1A plain search_path shadowing via evil.row_to_json(anyelement), 1B exact-type overload via public.row_to_json(app.accounts), 1C direct replacement of audit.if_modified() with a no-op followed by verbatim restoration, 2G a current_setting('app.maint') gated dormant bypass, and 3P direct insertion of forged audit rows with fake user/IP/timestamp. scripts/30_defenses.sql adds a DDL event-trigger guard (audit.ddl_watch, audit.ddl_record, audit.on_ddl) and a hash-chained append-only sink (audit.secure_log, audit.secure_append, audit.secure_verify). scripts/40_snapshot.sql fingerprints functions/triggers before and after attacks to assess reversibility. scripts/run_matrix.sh orchestrates the full PostgreSQL matrix across versions 14 and 16, while scripts/mysql/run_matrix_mysql.sh does the same for MariaDB 10.6 and 10.11. Core exploit capability: under specific database misconfigurations, a low-privilege application role reachable through SQL injection can blind or selectively bypass in-database trigger auditing and poison attribution from within the database. The strongest PostgreSQL vector is 1B: if public is writable and the SECURITY DEFINER trigger function has an unpinned search_path, an attacker can create public.row_to_json(app.accounts) returning NULL, causing audited row payloads to be suppressed. This is reported as reachable on stock PostgreSQL <=14 and misconfiguration-gated on 15+. Vector 1C requires ownership/ALTER rights over the audit function and allows replacing the function body to skip logging, then restoring the original definition byte-for-byte so object-diffing appears clean. Vector 2G adds a dormant per-session bypass controlled by app.maint. Vector 3P forges audit rows directly when INSERT on the audit table is granted. MariaDB lacks the search_path shadowing class, but trigger replacement, dormant bypass, and attribution poisoning are reproduced when TRIGGER and/or audit INSERT privileges are granted. There are no external C2 endpoints or victim internet hosts. Network exposure is limited to local Docker port mappings on localhost:55432 for PostgreSQL and localhost:55433 for MariaDB. The repository repeatedly emphasizes synthetic data and local-only execution. Overall, this is a reproducible proof-of-concept research lab demonstrating anti-forensic weaknesses in trigger-based database auditing and evaluating mitigations, rather than a general-purpose exploit framework.

This repository is a safe, local proof-of-concept demonstration of CVE-2018-1058 in PostgreSQL: uncontrolled search_path resolution allowing an attacker-controlled object in a writable schema to shadow an expected built-in object. The repo is not part of a larger exploit framework and contains 8 files total: one README, one docker-compose definition, and six SQL scripts implementing vulnerable setup, hardened setup, exploit, mitigation verification, victim trigger, and cleanup/fix logic. Repository structure and purpose: - README.md documents the demo workflow, expected outputs, and explains that this is a benign classroom-style reproduction of the root cause rather than the exact historical pg_dump path. - docker-compose.yml defines two PostgreSQL containers: postgres:10.2 as the vulnerable environment on host port 15432 and postgres:10.3 as the hardened comparison environment on host port 15433. - scripts/init.sql initializes the vulnerable database demo_cve1058, creates sample table people, creates attacker and victim roles, and crucially grants CREATE on schema public to attacker. - scripts/init_safe.sql initializes the hardened comparison environment similarly but revokes CREATE on schema public, preventing the exploit. - scripts/exploit.sql is the main exploit artifact. It creates public.exploit_log and a malicious overload public.lower(varchar) that logs invocation and returns attacker-controlled prefixed output. - scripts/victim_query.sql triggers the issue by executing SELECT lower(full_name) FROM people; without schema qualification. - scripts/verify_qualify.sql demonstrates mitigation by explicitly calling pg_catalog.lower(full_name::text), bypassing the attacker object. - scripts/fix.sql removes the malicious function/table and revokes CREATE on schema public. Main exploit capability: The exploit does not execute OS commands or establish shells. Its capability is SQL-level function hijacking through search-path abuse. By creating public.lower(varchar), the attacker causes a victim's unqualified lower(full_name) call to resolve to attacker code instead of the intended built-in function. The payload proves execution by inserting rows into public.exploit_log and altering returned strings to include the prefix 'CVE-2018-1058 DEMO:'. Targeting and conditions: The target is PostgreSQL, specifically a vulnerable configuration exemplified here with version 10.2 where attacker-controlled CREATE privileges exist on schema public. The hardened comparison on 10.3 demonstrates the patched/default-safe behavior where exploit.sql fails with 'permission denied for schema public'. Operational assessment: This is a real exploit demonstration, but clearly a benign POC rather than a weaponized exploit. It requires local or reachable database access plus valid credentials for attacker and victim roles. It is not a detection-only script and not fake; it reliably demonstrates the vulnerable name-resolution behavior and the mitigation.