CVE-2020-14349: PostgreSQL SQL Injection Vulnerability

CVE-2020-14349 Overview

A SQL injection vulnerability was discovered in PostgreSQL that allows an authenticated attacker to execute arbitrary SQL commands through improper sanitization of the search_path during logical replication. This flaw is similar to CVE-2018-1058 and affects PostgreSQL versions before 12.4, before 11.9, and before 10.14. An attacker with valid credentials can exploit this vulnerability to execute malicious SQL commands in the context of the user used for replication, potentially leading to data exfiltration, modification, or privilege escalation within the database environment.

Critical Impact

Authenticated attackers can execute arbitrary SQL commands in the replication user context, potentially compromising database integrity and confidentiality.

Affected Products

• PostgreSQL versions before 12.4
• PostgreSQL versions before 11.9
• PostgreSQL versions before 10.14
• openSUSE Leap 15.1
• openSUSE Leap 15.2

Discovery Timeline

• 2020-08-24 - CVE-2020-14349 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2020-14349

Vulnerability Analysis

This vulnerability stems from PostgreSQL's failure to properly sanitize the search_path parameter during logical replication operations. The search_path setting determines the order in which schemas are searched when an object name is referenced without explicit schema qualification. By manipulating this parameter, an attacker can cause PostgreSQL to resolve function or object names to malicious implementations in attacker-controlled schemas instead of the intended system objects.

During logical replication, the database executes various internal operations using the replication user's privileges. When the search_path is not properly sanitized, an attacker can inject a schema containing trojanized versions of commonly-used functions. When the replication process calls these functions without schema qualification, the malicious versions are executed instead, running arbitrary SQL code with the replication user's elevated privileges.

Root Cause

The root cause is classified under CWE-89 (SQL Injection). PostgreSQL's logical replication subsystem did not implement adequate input validation and sanitization for the search_path configuration parameter. This allowed the injection of schema names that could redirect function resolution to attacker-controlled implementations, bypassing the expected execution flow and enabling arbitrary SQL command execution.

Attack Vector

This is a network-based attack that requires authentication to the PostgreSQL database. The attacker must have valid credentials to access the database system. The attack complexity is considered high as it requires specific conditions related to logical replication configuration. Additionally, user interaction may be required in certain exploitation scenarios.

The attack proceeds through the following mechanism:

1. The attacker establishes an authenticated connection to the PostgreSQL database
2. The attacker creates a malicious schema containing trojanized functions that mimic system functions
3. The attacker manipulates the search_path to include their malicious schema with higher priority
4. During logical replication operations, unqualified function calls resolve to the malicious implementations
5. The attacker's SQL commands execute with the privileges of the replication user

Detection Methods for CVE-2020-14349

Indicators of Compromise

• Unexpected schema creation or modification by non-administrative users
• Unusual search_path configurations in database sessions, especially during replication
• Presence of user-defined functions with names matching common system functions in non-system schemas
• Anomalous SQL query patterns during logical replication processes

Detection Strategies

• Monitor PostgreSQL logs for search_path modifications during replication sessions
• Implement database activity monitoring (DAM) to detect schema manipulation and suspicious function creation
• Query system catalogs (pg_namespace, pg_proc) for user-created objects that shadow system functions
• Review replication user privileges and ensure they follow the principle of least privilege

Monitoring Recommendations

• Enable and regularly review PostgreSQL audit logging with focus on DDL statements
• Set up alerts for search_path changes involving non-standard schemas
• Monitor for new function definitions that match names of PostgreSQL built-in functions
• Implement real-time monitoring of replication slot activity and associated session parameters

How to Mitigate CVE-2020-14349

Immediate Actions Required

• Upgrade PostgreSQL to version 12.4, 11.9, or 10.14 or later immediately
• Audit current search_path configurations across all database users
• Review and restrict privileges of replication users to minimum necessary
• Examine existing schemas for potentially malicious function definitions

Patch Information

PostgreSQL has released security patches addressing this vulnerability. Organizations should upgrade to the following minimum versions:

• PostgreSQL 12.x: Upgrade to version 12.4 or later
• PostgreSQL 11.x: Upgrade to version 11.9 or later
• PostgreSQL 10.x: Upgrade to version 10.14 or later

For additional information, refer to the Ubuntu Security Notice, Gentoo GLSA Overview, NetApp Security Advisory, or the Red Hat Bug Report.

Workarounds

• Explicitly set search_path to include only trusted schemas for replication users: ALTER ROLE replication_user SET search_path = pg_catalog, public;
• Revoke CREATE privileges on public schema from PUBLIC to prevent unauthorized function creation
• Use fully schema-qualified function names in all custom code and triggers
• Implement strict schema permission controls to prevent untrusted users from creating schemas

# Configuration example: Restrict search_path for replication users
psql -U postgres -c "ALTER ROLE replication_user SET search_path = pg_catalog, public;"
psql -U postgres -c "REVOKE CREATE ON SCHEMA public FROM PUBLIC;"
psql -U postgres -c "GRANT USAGE ON SCHEMA public TO replication_user;"