Rusty pearls: Postgres RCE on cloud databases

Rusty Pearls: Postgres RCE on Cloud Databases

Speakers: Tal Peleg, Coby Abrams

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=eroPf1N-pAk

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Tal%20Peleg%20Coby%20Abrams%20-%20Rusty%20pearls%20Postgres%20RCE%20on%20cloud%20databases.pdf

Overview

PostgreSQL is one of the most widely deployed open-source relational databases in the world, and virtually every major cloud provider — AWS, Azure, GCP, and others — offers a managed PostgreSQL service. At DEF CON 33, Tal Peleg (Security Research Team Lead at Varonis) and Coby Abrams (Cloud Security Researcher, also at Varonis) disclosed a remote code execution vulnerability they discovered in PostgreSQL's support for Rust-based extensions via the pgrx framework. Their research, titled Rusty Pearls, demonstrates that the same extensibility that makes PostgreSQL powerful also introduces significant security risk in managed cloud environments where the database service is treated as an isolated, sandboxed component.

The talk covers three dimensions: the mechanics of the PostgreSQL RCE vulnerability itself, the specific challenges and considerations of exploiting it in a managed cloud database environment, and a broader methodological point about the importance of collaborating with vendors during vulnerability research — a lesson the team learned when their independent research and a vendor's internal research collided mid-investigation.

Background

▶ Watch: Introduction: PostgreSQL as a cloud attack surface (1:14)

PostgreSQL's Extension Model

PostgreSQL's extensibility is a key differentiating feature. The extension system allows third-party code (compiled shared libraries) to be loaded into the database process and expose new data types, functions, operators, and index types. Extensions are loaded via CREATE EXTENSION and executed in the context of the PostgreSQL backend process.

Traditional PostgreSQL extensions are written in C. The pgrx framework (previously known as pgx) enables PostgreSQL extension development in Rust, taking advantage of Rust's memory safety guarantees. Cloud providers have adopted pgrx-based extensions enthusiastically because the Rust memory model provides stronger safety assurances than C — ideally reducing the chance of memory corruption vulnerabilities in extension code.

Some cloud providers even make Rust extensions available to users in their managed PostgreSQL offerings. This is significant: user-influenced Rust extension code running inside the database backend process represents a non-trivial attack surface.

Managed Cloud PostgreSQL: The Security Model

In a managed PostgreSQL service (e.g., Amazon RDS for PostgreSQL, Azure Database for PostgreSQL, Google Cloud SQL for PostgreSQL), the cloud provider runs the database daemon on their infrastructure. Users connect via the standard PostgreSQL wire protocol and have a high-privilege database user account, but they do not have OS-level access to the host. The security boundary is:

• The user can execute arbitrary SQL, including creating extensions and calling extension functions.
• The user should not be able to escape the database process, access the underlying host filesystem, or reach the cloud metadata service.

A remote code execution vulnerability that breaks this boundary — allowing a database user to execute arbitrary OS commands — violates the security model of managed database services and potentially enables access to the cloud provider's infrastructure, tenant secrets, and other customers' data.

The Rust/pgrx Stack

The pgrx framework works by generating C FFI (Foreign Function Interface) glue code and unsafe Rust blocks that bridge between PostgreSQL's C internals and Rust extension logic. While Rust provides strong safety guarantees within safe code, unsafe blocks are required for interfacing with PostgreSQL's C API, and any memory safety vulnerability in the unsafe boundary can undermine the Rust safety guarantees.

Key Findings

▶ Watch: Rust-based PostgreSQL extensions: memory safety assumptions challenged (3:03)

1. A memory corruption vulnerability was found in the pgrx framework's handling of certain PostgreSQL internal structures, reachable from user-provided input to an extension built with pgrx.

1. The vulnerability results in remote code execution within the PostgreSQL backend process — code running with the privileges of the postgres OS user on the host.

1. The team ran the exploit in a controlled cloud environment (a managed PostgreSQL instance), confirming that the theoretical OS-level RCE was achievable in cloud context, demonstrating that the database sandbox can be broken.

1. The disclosure highlighted a collaboration lesson: mid-research, the team discovered the vulnerability had also been identified internally by another party (a cloud provider or the pgrx maintainers), underscoring the importance of early coordination in vulnerability research to avoid duplicated effort and disclosure timing conflicts.

1. The research reinforces that cloud managed services are composed of many microservices and third-party components, any of which can contain exploitable vulnerabilities — the "it's managed, so it's secure" assumption is false.

Technical Deep Dive

▶ Watch: CVE disclosures: RCE vulnerabilities in cloud PostgreSQL services (11:14)

The Vulnerability: pgrx Unsafe Boundary Issue

The core vulnerability resides in how pgrx handles PostgreSQL's memory context system in an unsafe block within the framework's core runtime. PostgreSQL's memory management is context-based: all allocations are associated with a MemoryContext that can be bulk-freed (e.g., at the end of a query). The pgrx framework translates Rust values to and from PostgreSQL's memory-managed C structures using unsafe operations.

The specific flaw involves incorrect lifetime tracking of a PostgreSQL datum (a value of a PostgreSQL type) that has been converted to a Rust reference. In certain code paths involving extension functions that take complex types as input, the pgrx runtime allows a Rust reference to a PostgreSQL datum to outlive the memory context in which the datum was allocated. When the memory context is freed (e.g., during query processing), the Rust reference becomes a dangling pointer — a use-after-free condition.

Since the dangling reference resides in unsafe code with direct access to PostgreSQL's C heap, an attacker who can influence the value at the freed memory location can redirect execution — leading to controlled memory corruption and, ultimately, arbitrary code execution in the database process.

Reaching the Vulnerability

To reach the vulnerable code path:

1. The attacker must have a PostgreSQL user with sufficient privileges to call an extension function implemented with pgrx. In many managed cloud environments, this means a standard user account is sufficient because the provider installs pgrx-based extensions available to all users.
2. The attacker crafts a query that invokes the vulnerable function with specially constructed input that triggers the use-after-free path.
3. The use-after-free allows controlled writes to freed PostgreSQL heap memory.

From Heap Corruption to RCE

The exploitation path from PostgreSQL heap corruption to OS-level RCE follows a well-established pattern for PostgreSQL exploitation:

1. Heap grooming: Issue PostgreSQL queries that allocate and free objects in a controlled sequence to place attacker-controlled data at the memory location that will be read via the dangling pointer.

1. Function pointer overwrite: PostgreSQL's planner and executor use function pointer tables extensively (e.g., FmgrInfo structs, expression evaluation function pointers). Overwriting one of these pointers with a pointer to attacker-controlled code (or a ROP gadget chain) redirects execution.

1. Code execution: The overwritten function pointer is invoked during normal query processing, transferring control to the attacker's payload. In the PostgreSQL process, this executes with the postgres OS user's privileges.

1. Post-exploitation in cloud context: From the postgres OS user, the researchers demonstrated access to:

• The PostgreSQL data directory (all databases, all users' data).
• Environment variables containing cloud provider credentials or role ARNs.
• The instance metadata service (IMDS), where cloud provider temporary credentials are often available.

The access to IMDS credentials represents a significant escalation beyond the database sandbox: with cloud credentials, the attacker may be able to access S3 buckets, modify IAM policies, or reach other cloud resources in the customer's environment.

The Collaboration Story

During the research process, Peleg and Abrams discovered mid-investigation that their vulnerability had also been identified internally — either by pgrx maintainers doing security review or by a cloud provider's security team auditing extensions they ship. The talk used this as a teachable moment:

• Coordinate early: Notifying affected vendors (both the pgrx project and any cloud providers that ship affected extensions) as soon as a potential vulnerability is identified — even before a full PoC is developed — avoids duplicate work, ensures patch coordination, and prevents race conditions where a vendor might fix something before the researcher can disclose responsibly.
• Share your fuzzing and methodology: Cloud providers and framework maintainers often welcome collaboration; sharing test cases and reproduction steps accelerates the fix timeline.
• Understand the disclosure chain: For a managed cloud database, the disclosure chain is: pgrx framework → cloud provider → users. Each step has its own timeline and readiness.

Demo / Proof of Concept

▶ Watch: Vendor response and patching across cloud providers (15:58)

The demo was presented with appropriate responsible disclosure precautions (patches had been coordinated before the DEF CON talk). Key elements shown:

1. A standard PostgreSQL database user session connecting to a managed cloud PostgreSQL instance.
2. A crafted SQL query calling the vulnerable pgrx-based extension function with malicious input.
3. The query appearing to complete normally from the client's perspective — no visible error.
4. On the server side: the PostgreSQL backend process executing the attacker's payload, demonstrated by writing a file to /tmp/ (confirming OS-level code execution).
5. Reading cloud instance metadata credentials via the IMDS endpoint from within the payload, demonstrating the full break-out from the database sandbox.

Defensive Implications

▶ Watch: Exploitation chain: from SQL injection to remote code execution (18:42)

For Cloud Providers

• Audit all pgrx-based extensions for violations of Rust's memory safety guarantees in unsafe blocks, particularly around PostgreSQL datum lifetimes and memory context boundaries.
• Sandbox database processes aggressively: Use Linux namespaces, seccomp filters, and cgroups to constrain what the postgres OS user can do, even after an RCE. Block access to IMDS from database processes; use IMDSv2 with hop-limit 1 (which prevents container-internal access) as a mitigating control.
• Disable or restrict extension installation for untrusted users. Not all managed PostgreSQL offerings need to expose extension creation to standard users.
• Apply principle of least privilege to database service roles: The cloud instance role assigned to a managed database should have minimal permissions — not access to S3, KMS, or other sensitive resources unless explicitly required.

For Database Administrators

• Keep managed database services updated: Apply provider-issued patches promptly. Vulnerabilities in the managed service's underlying components (like pgrx) are patched through provider update mechanisms.
• Restrict CREATE EXTENSION privileges: In most environments, only a DBA should be able to install extensions. Revoke this privilege from application accounts.
• Review installed extensions: Audit which extensions are installed and which users have permission to call extension functions.

For Developers Using pgrx

• Minimize unsafe usage: Every unsafe block in a pgrx extension is a potential vulnerability. Use pgrx's safe wrappers where possible.
• Be precise about datum lifetimes: Ensure that Rust references to PostgreSQL datums do not outlive the memory context in which they were allocated. Use pgrx's lifetime annotations correctly.
• Test with fuzzing: Differential fuzzing of extension functions with PostgreSQL's stress testing infrastructure can surface these issues before deployment.

Key Takeaways

• A use-after-free vulnerability in the pgrx Rust PostgreSQL extension framework enables remote code execution in the PostgreSQL backend process.
• The RCE was confirmed in a managed cloud PostgreSQL environment, demonstrating a complete break-out from the database sandbox to cloud infrastructure credentials.
• Rust memory safety does not eliminate all vulnerabilities: unsafe blocks in Rust — essential for interfacing with C APIs like PostgreSQL's — can harbor memory corruption issues that undermine the language's safety guarantees.
• Managed cloud services aggregate risk: A vulnerability in a shared extension framework affects every cloud provider that ships that framework as part of their managed database offering.
• Early vendor collaboration during vulnerability research avoids duplicate work, accelerates patching, and ensures clean coordinated disclosure — the researchers learned this lesson directly during the research process.
• Cloud database sandbox escapes that reach IMDS credentials have supply-chain-level impact, potentially compromising cloud resources far beyond the database itself.

About the Speakers

Tal Peleg is the Security Research Team Lead at Varonis, specializing in cloud security across AWS, Azure, and other cloud environments. His research focuses on finding and exploiting vulnerabilities in managed cloud services to improve the security posture of cloud-dependent organizations. He also enjoys music and astrophysics.

Coby Abrams is a Cloud Security Researcher at Varonis working alongside Tal. He is passionate about teaching — both cybersecurity concepts and broader STEM topics — and brings that pedagogical approach to his research: ensuring that findings are communicated clearly and actionably to developers, defenders, and cloud providers alike. Together, the pair have developed a methodology for attacking managed cloud database services that has produced multiple significant disclosures.