Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM

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(dot)bapat(dot)oss(at)gmail(dot)com>
wrote:

> On Wed, Dec 3, 2025 at 4:08 PM Ignat Remizov <ignat980(at)gmail(dot)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
>