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

Поиск
Список
Период
Сортировка
От Ignat Remizov
Тема Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
Дата
Msg-id CAKiC8XbZf2fMV_w=eNdNWoz+uOSWqXLWJVpxArFriD_Riowfuw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Ответы Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
Список 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 по дате отправления: