Skip to content

Latest commit

 

History

History
89 lines (58 loc) · 5.79 KB

cve-2024-7348-postgres-upgrade.mdx

File metadata and controls

89 lines (58 loc) · 5.79 KB
Raw
title description image author authorEmail date tags published slug ogImage
Why you should upgrade PostgreSQL today
Upgrade PostgreSQL today to avoid CVE-2024-7348 vulnerability
Gulcin Yildirim Jelinek
gulcin@xata.io
08-09-2024
postgres
cve
upgrade
vulnerability
true
cve-2024-7348-postgres-upgrade

Why Should You Upgrade Your PostgreSQL Today? 🦉

If you're running PostgreSQL versions 12, 13, 14, 15, or 16 and haven’t yet upgraded to the latest minor versions released on August 8, 2024, you might be exposed to a critical security vulnerability known as CVE-2024-7348. This vulnerability could allow attackers to execute arbitrary SQL code during pg_dump operations as the user running pg_dump, potentially compromising your entire database.

The Vulnerability: CVE-2024-7348

CVE-2024-7348 is a Time-of-Check Time-of-Use (TOCTOU) race condition vulnerability in pg_dump, a utility used for backing up PostgreSQL databases. This vulnerability allows an attacker to replace a relation type (such as a table or sequence) with a view or foreign table right when pg_dump is running. Because pg_dump often runs with superuser privileges, this attack could execute arbitrary SQL code, leading to unauthorized actions or data corruption.

Affected Versions:

  • PostgreSQL 12 (before 12.20)
  • PostgreSQL 13 (before 13.16)
  • PostgreSQL 14 (before 14.13)
  • PostgreSQL 15 (before 15.8)
  • PostgreSQL 16 (before 16.4)

If your PostgreSQL instance falls within any of these versions and has not been upgraded to the latest minor release, you are vulnerable to this exploit.

Understanding the Risk

The attack described in CVE-2024-7348 is not just theoretical. An attacker with sufficient privileges to create and drop objects in the database could inject malicious SQL that pg_dump would then execute. This could be devastating, especially if pg_dump is running as a superuser, which is often the case in many environments.

Here’s how the attack works:

  • The attacker creates a non-temporary object in the database, like a sequence.
  • Just before pg_dump begins, the attacker replaces this object with a view or a foreign table that contains malicious SQL.
  • When pg_dump attempts to back up the database, it inadvertently executes the injected SQL code.

This sequence of actions is possible because pg_dump checks the type of object before starting the backup, but due to the race condition, the object can be replaced before the actual backup begins. The vulnerability hinges on the fact that the backup process trusts the integrity of database objects without verifying them at every step of the operation.

How the PostgreSQL Team Addressed the Issue

To mitigate this vulnerability, the PostgreSQL team introduced a fix in the latest minor releases. The fix involves a new server parameter, restrict_nonsystem_relation_kind, which limits the ability to expand non-builtin views and access foreign tables during pg_dump. This parameter, when set, effectively closes the loophole that allows the race condition to be exploited.

However, it's important to note that the protection is only active if both pg_dump and the server are updated to the versions containing the fix. If either side is running an older version, the vulnerability could still be exploited.

Our Experience at Xata

We first noticed the issue when a user reported a failing pg_dump query in the Xata Discord help channel.

Huh, that looks like a new parameter

The same error soon started appearing in some of our CI tests:

pg_dump: error: query failed: couldn't get first string argument
pg_dump: detail: Query was: SELECT set_config(name, 'view, foreign-table', false) FROM pg_settings WHERE name = 'restrict_nonsystem_relation_kind'

While checking the query, we noticed the restrict_nonsystem_relation_kind parameter being introduced that is linked to CVE-2024-7348.

For the query itself, we noticed the issue is on our side and began working on a fix, as shared by Tudor in our Discord channel:

A quick fix from the Xata team

If you'd like to join our friendly community, here's an invite to our Discord: Xata Discord.

What You Should Do Next

Upgrade Immediately: If you're running an affected version of PostgreSQL, the solution is simple—upgrade to the latest minor version immediately. The following versions include the fix:

  • PostgreSQL 12.20
  • PostgreSQL 13.16
  • PostgreSQL 14.13
  • PostgreSQL 15.8
  • PostgreSQL 16.4

Test After Upgrading: After upgrading, thoroughly test your database operations, especially any automated backups or pg_dump processes, to ensure they function correctly and securely.

Review User Permissions: Consider reviewing the permissions of users who can create or drop database objects. Restricting these privileges can further reduce the risk of exploitation, even if a similar vulnerability arises in the future.

Conclusion

Security vulnerabilities like CVE-2024-7348 remind us of the importance of staying current with software updates, especially for mission-critical infrastructure like databases. By upgrading to the latest PostgreSQL versions, you not only protect your data but also ensure the continued reliability and security of your applications.