Pwning Cloud Vendors with Untraditional PostgreSQL Vulnerabilities

Overview: Shir Tamari and Nir Ohfeld of the Wiz research team present an investigation into the security architectures of managed PostgreSQL Database-as-a-Service (DBaaS) offerings across major cloud providers. Building on their prior ChaosDB research, the authors examine the attack surface exposed when cloud vendors modify open-source database engines to run in multi-tenant or managed environments. The presentation demonstrates how custom privilege modifications in Google Cloud SQL introduced privilege escalation and tenant boundary bypasses.

Key Topics: - Cloud DBaaS threat models and command execution via PostgreSQL COPY ... FROM PROGRAM - Cloud vendor privilege decoupling: cloudsqlsuperuser versus internal cloudsqladmin - Security implications of custom vendor modifications to PostgreSQL core engine logic - Exploiting table ownership alteration, event triggers, and custom extensions to hijack admin execution

Technical Details: In PostgreSQL environments, arbitrary operating system command execution is natively achievable via the COPY <table> FROM PROGRAM '<command>' statement. To prevent arbitrary code execution on host virtual machines, cloud providers universally restrict standard SUPERUSER privileges from managed database accounts, returning permission denied errors when users attempt to execute commands. However, stripping native superuser rights conflicts with customer requirements to manage operational features, prompting vendors to introduce custom role architectures and modify database engine source code.

In Google Cloud SQL, the default customer administrative account postgres is assigned the custom cloudsqlsuperuser role rather than native superuser rights, while cloud operations are managed internally via a true superuser account named cloudsqladmin. To provide necessary administrative utility, Google modified PostgreSQL to grant cloudsqlsuperuser specific elevated capabilities: loading extensions, defining event triggers, and creating replication users. Crucially, Google also modified table ownership controls, allowing a cloudsqlsuperuser to execute ALTER TABLE <name> OWNER TO cloudsqladmin, assigning ownership of user-created tables to the internal administrative superuser without belonging to that role—an operation explicitly forbidden by standard PostgreSQL.

The Wiz researchers identified that modifying core PostgreSQL security primitives introduced dangerous execution hijacking primitives. In standard PostgreSQL, table and index operations execute within defined security contexts. By creating malicious custom database objects, defining triggers or operators, and transferring object ownership to cloudsqladmin, a low-privileged customer account could coerce internal Google maintenance procedures into executing untrusted SQL code under the context of the internal superuser. This capability broke tenant isolation and bypassed Google's security restrictions, allowing escalation to full superuser status and host-level inspection.

Key Takeaways: Cloud providers that modify open-source software to implement custom privilege tiers often introduce critical privilege escalation flaws by breaking upstream security invariants. Stripping superuser rights while selectively re-enabling dangerous primitives (such as arbitrary ownership transfer or event triggers) creates subtle execution hijacking vectors. Managed service security requires defense-in-depth isolation at the container and VM hypervisor layers rather than relying solely on modified application-layer role abstractions.

(AI summary — Gemini Flash)