| From: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
|---|---|
| To: | Ignat Remizov <ignat980(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM |
| Date: | 2025-12-03 11:30:49 |
| Message-ID: | CAExHW5s+iQPVjAKsqAgUt-LdraZD4XgmodpV5CnfSF8ES8NxWA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | cca5507 | 2025-12-03 11:48:10 | Support loser tree for k-way merge |
| Previous Message | Dilip Kumar | 2025-12-03 11:26:49 | Re: Proposal: Conflict log history table for Logical Replication |