Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM - Mailing list pgsql-hackers

From Ignat Remizov
Subject Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
Date
Msg-id CAKiC8XbZf2fMV_w=eNdNWoz+uOSWqXLWJVpxArFriD_Riowfuw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
List pgsql-hackers
Thanks for looking, Ashutosh.

pg_execute_server_program is sufficient for non‑superusers, but superusers
always bypass it. In the incident that prompted this, the attacker obtained
superuser via weak/default creds on an exposed instance (common in shared dev
or staging setups). From there, COPY PROGRAM is the simplest, most common RCE
vector used by botnets. The GUC is a defense‑in‑depth knob to let an admin
disable that specific path even for superuser, while leaving the feature
available by default for existing users.

The patch just removes the lowest‑hanging RCE primitive when you explicitly
turn it off (requiring a restart, not ALTER SYSTEM/SET). Default remains on to
preserve current behavior.

--
Ignat Remizov




On Wed, Dec 3, 2025 at 1:31 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote:
On Wed, Dec 3, 2025 at 4:08 PM Ignat Remizov <ignat980@gmail.com> wrote:
>
> Hi Postgres hackers,
>
> Attached is a patch that introduces a new server-level configuration
> parameter, "enable_copy_program", that allows administrators to disable
> COPY ... PROGRAM functionality at the PostgreSQL server level.
>
>
> MOTIVATION
> ==========
>
> COPY ... PROGRAM is a powerful feature that allows executing arbitrary
> shell commands from within PostgreSQL. While access is controlled via
> the pg_execute_server_program role, some deployments may want to
> completely disable this capability as a defense-in-depth measure.
> This GUC provides that option.
>
> In practice, COPY ... PROGRAM is a common code execution vector in
> PostgreSQL-based attacks. It is:
>
>   - Simple to use (single SQL statement)
>   - Requires no additional extensions or setup
>   - Frequently targeted by automated botnets and malware campaigns
>   - Often the first technique attempted by attackers who gain superuser access
>
> While this GUC is not a comprehensive security solution, it serves as a
> mitigating control that removes some of the lowest-hanging fruit for
> attackers.
>
>
> IMPORTANT SECURITY CONTEXT
> ==========================
>
> This is a mitigating control, not a security boundary.
>
> There is ongoing ecosystem friction around the disputed CVE-2019-9193 entry
> in the NVD. The PostgreSQL Security Team has stated that this CVE does not
> represent a security bug in PostgreSQL and was filed in error, but NVD and
> other CVE databases still list it as a remote code execution issue via COPY
> TO/FROM PROGRAM, and several commercial scanners and IDS/IPS signatures treat
> it as a high-severity vulnerability. This patch is not intended as a fix for
> that CVE; it simply provides an explicit configuration knob for administrators
> whose security tooling or policies require disabling program execution via COPY.
>
> Superusers retain multiple other avenues for executing operating system
> commands, including but not limited to:
>
>   - Untrusted procedural languages (CREATE EXTENSION plpythonu, plperlu, etc.)
>   - Custom extensions that provide shell access
>   - The LOAD command to load arbitrary shared libraries
>   - pg_read_file() / pg_write_file() combined with other techniques
>   - Foreign data wrappers with program execution capabilities
>   - Background workers in custom extensions
>
> Disabling COPY ... PROGRAM does NOT make PostgreSQL secure against a
> malicious superuser. However, it does:
>
>   1. Block a very common and highly automated attack vector – many botnet
>      payloads and exploit scripts specifically target COPY ... PROGRAM
>      because it requires no prerequisites.
>
>   2. Raise the bar for exploitation – attackers must use more complex,
>      less portable, or more detectable methods.
>
>   3. Reduce drive-by attacks – automated scanners and opportunistic
>      attackers often give up when their standard payload fails.
>
>   4. Help meet compliance requirements – some security frameworks mandate
>      disabling specific high-risk features.
>
>   5. Provide defense in depth – one layer in a broader security strategy.
>

If pg_execute_server_program is not granted to any user, the
functionality is already disabled right? Why do we need additional GUC
to enable/disable this feature?

--
Best Wishes,
Ashutosh Bapat

pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: Returning nbtree posting list TIDs in DESC order during backwards scans
Next
From: "cca5507"
Date:
Subject: Re: Support loser tree for k-way merge