Bug 1695982 (CVE-2019-9193) - CVE-2019-9193 postgresql: Command injection via "COPY TO/FROM PROGRAM" function
Summary: CVE-2019-9193 postgresql: Command injection via "COPY TO/FROM PROGRAM" function
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2019-9193
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1695983 1695984 1695985
Blocks: 1695986
TreeView+ depends on / blocked
 
Reported: 2019-04-04 01:23 UTC by Pedro Sampaio
Modified: 2019-09-29 15:10 UTC (History)
33 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-04 17:03:31 UTC


Attachments (Terms of Use)

Description Pedro Sampaio 2019-04-04 01:23:54 UTC
In PostgreSQL 9.3 through 11.2, the "COPY TO/FROM PROGRAM" function allows superusers and users in the 'pg_read_server_files' group to execute arbitrary code in the context of the database's operating system user. This functionality is enabled by default and can be abused to run arbitrary operating system commands on Windows, Linux, and macOS.

References:

https://medium.com/greenwolf-security/authenticated-arbitrary-command-execution-on-postgresql-9-3-latest-cd18945914d5

Comment 1 Pedro Sampaio 2019-04-04 01:24:15 UTC
Created mingw-postgresql tracking bugs for this issue:

Affects: epel-7 [bug 1695984]
Affects: fedora-all [bug 1695985]


Created postgresql tracking bugs for this issue:

Affects: fedora-all [bug 1695983]

Comment 2 Tom Lane 2019-04-04 03:39:23 UTC
The position of the Postgres project is that this CVE was written by somebody who hasn't troubled to understand Postgres' security model.  There is no bug, and we are thinking of filing a dispute of the CVE with Mitre.

There's an unofficial response from another core member here:
https://blog.hagander.net/when-a-vulnerability-is-not-a-vulnerability-244/

Another public discussion is here:
https://www.postgresql.org/message-id/flat/e6251b54-78f4-4ec0-8e22-8c4179f0e817%40manitou-mail.org

The official response, if any, is likely to consist of improving the documentation to make it clear that there's no security boundary between database superusers and the OS account running the server.  You can more or less understand that from existing statements in the docs, but we haven't spelled it out in exactly those words.

Comment 3 Patrik Novotný 2019-04-04 17:03:31 UTC
As the reported behaviour is actually expected (and documented) functionality, and the CVE seems to be filed by error/misunderstanding, I'm closing this as not a bug.

Read official upstream response here:
https://www.postgresql.org/about/news/1935/

Comment 5 Doran Moppert 2019-04-08 05:22:21 UTC
Statement:

The PostgreSQL Project does not consider this to be a vulnerability. By design, database super users have full rights to the context that PostgreSQL executes within, including reading & writing all files and code execution. See External References for more details.

Red Hat Product Security concurs with upstream's assessment that this is not a vulnerability. Customers are advised to follow best practice when configuring PostgreSQL, which includes allocating only the minimum privileges to users. Super user privileges in particular must be very carefully controlled.

Comment 6 Doran Moppert 2019-04-08 05:22:22 UTC
External References:

https://www.postgresql.org/about/news/1935/


Note You need to log in before you can comment on or make changes to this bug.