PostgreSQL 12.4 secures name lookup during privileged work

Permission to create an object can become permission to influence someone else's SQL when name lookup searches that object's schema. PostgreSQL 12.4 closes two vulnerabilities involving privileged work performed with unsafe search paths. The August 13 announcement identifies logical replication and extension installation as the affected operations. Both cases require attention to who can create the objects a privileged operation might resolve.

The release includes fixes for supported maintenance branches as well as another PostgreSQL 13 beta. For an existing installation, the relevant security changes belong to its maintained major branch. A new major-version migration is not required to obtain them. The announcement describes the ordinary cumulative minor-update procedure of shutting down and replacing binaries, with earlier release instructions still relevant when previous updates were skipped.

I value PostgreSQL's extension system, but configurable name resolution adds a trust decision to that flexibility. A function name that looks familiar in a script does not establish which function will run. The database must resolve it in an environment whose object creators are appropriate for the authority executing the script.

A schema in the path confers trust

The schema documentation shipped with 12.4 explains that an unqualified name searches schemas in order. The first matching object determines the reference. A matching table somewhere else in the database does not help when that schema is absent from the path. For an unqualified creation command, the first existing schema also determines where the new object goes.

This makes the path more than a convenience for shorter SQL. The documentation explicitly treats a schema in search_path as trust in users who can create objects there. Functions and operators participate in name resolution as well as tables. A review restricted to visible table names can therefore miss an expression's dependency on the lookup environment.

One inspection command establishes the configured value:

SHOW search_path;

The result needs to be interpreted alongside schema privileges. Knowing a schema's name does not identify everyone entitled to populate it. The security question concerns the combination of lookup order and object creation authority, especially when the caller has privileges unavailable to those object creators.

Logical replication left a lookup gap

The CVE-2020-14349 advisory explains the history. The earlier CVE-2018-1058 repair sanitized search_path in most PostgreSQL client applications. Logical replication still left it unchanged. A user in a publisher or subscriber database could create objects in public that caused functions to execute under the replication identity, often a superuser.

The affected maintained major versions are 10 through 12. The advisory says installations following a documented secure schema usage pattern are not vulnerable. That qualification is significant because the attack depends on the ability to introduce objects where privileged lookup will find them. It does not mean every database using logical replication is exposed in the same way.

The replication role's authority matters to the consequence. Resolving a hostile function is dangerous because the privileged operation supplies the execution identity. The attacker need not persuade the administrator to type the function's explicit name. The routine replication operation can encounter it through ordinary name resolution. That is why changing SQL spelling in an application is an incomplete description of the repair.

Empty paths change compatibility too

The 12.4 release notes say replication senders and receivers now execute with empty search_path settings. They also warn that insufficiently qualified names in replicated tables' DDL can cause problems after this change. Restricting lookup can expose an existing reliance on ambient schema names.

This compatibility effect follows the same mechanism as the security repair. A name that previously resolved through a permissive path may no longer resolve that way. Qualification makes the intended relationship explicit where that is required. The release notes separately acknowledge risks inherent in replicating objects owned by untrusted roles, which cannot all be removed by emptying the path.

I prefer this explanation to treating every post-update lookup failure as an unrelated regression. The changed environment is deliberate. Its purpose is to prevent a privileged process from accepting object definitions supplied through an unsafe path, and some existing definitions may have relied on exactly that environment.

Extension scripts require their own review

The second advisory, CVE-2020-14350, concerns certain CREATE EXTENSION statements executed by a superuser. An attacker needs object creation privileges in the target schema or in a prerequisite extension's schema. Not all extensions are vulnerable. The project repairs its supplied extensions and provides guidance for third-party authors, so upgrading the server does not establish that every external extension script is secure.

The extension author guidance in this release recommends secure lookup when scripts execute general SQL. It describes temporarily using pg_catalog followed by pg_temp and explicitly qualifying references to the installation schema. Commands containing general expressions deserve scrutiny even when they occur inside a DDL statement. A CREATE VIEW or a function default can contain expressions whose resolution matters.

The guidance also warns against unnecessary CREATE OR REPLACE FUNCTION in installation scripts. Replacing an existing function can leave its original owner in control of that function, which creates a separate security problem. Update scripts that intentionally replace known extension members have a different reason to use that form. The distinction requires the author to know which existing object is being changed, rather than relying on replacement syntax to make installation succeed.

For an administrator, the practical consequence is a review of both ownership and lookup. A schema name establishes a location, while its privileges establish who can influence that location's contents. An extension dependency introduces another schema whose permissions matter during installation. Recording the intended owners and qualifying the intended references gives a script reviewer concrete evidence about those decisions, instead of asking the reviewer to assume that every object encountered by a superuser is trustworthy.