Recently, references to a "new PostgreSQL vulnerability" has been circling on social media (and maybe elsewhere). It's even got it's own CVE entry (CVE-2019-9193). The origin appears to be a blogpost from Trustwave.
So is this actually a vulnerability? (Hint: it's not) Let's see:
To quote the post:
Since version 9.3, new functionality for ‘COPY TO/FROM PROGRAM’ was implemented. This allows
the database superuser, and any user in the ‘pg_read_server_files’ group to run arbitrary
operating system commands. This effectively means there is no separation of privilege
between a database superuser user and the user running the database on the operating system.
And then to quote the PostgreSQL documentation:
COPY with a file name instructs the PostgreSQL server to directly read from or write
to a file. The file must be accessible by the PostgreSQL user (the user ID the server
runs as) and the name must be specified from the viewpoint of the server. When PROGRAM
is specified, the server executes the given command and reads from the standard output
of the program, or writes to the standard input of the program. The command must be
specified from the viewpoint of the server, and be executable by the PostgreSQL user.
COPY naming a file or command is only allowed to database superusers or users who are
granted one of the default roles pg_read_server_files, pg_write_server_files, or
pg_execute_server_program, since it allows reading or writing any file or running
a program that the server has privileges to access.
and
Executing a command with PROGRAM might be restricted by the operating system's access
control mechanisms, such as SELinux.
So what we have here is simply PostgreSQL acting exactly as intended, and as documented. The "vulnerability" is the same as the fact that if you log in as root on your typical Unix system, you can edit and create file and run commands as... root.
While COPY FROM PROGRAM has made it a bit easier, it is by no means the only way to execute commands as the server user, if superuser permissions have been granted. Given that the superuser can read and write arbitrary files on the server (as the postgres user), it can fairly easily be escalated into running commands even without COPY FROM PROGRAM.
(The post is also factually incorrect in that members of pg_read_server_files can run commands. That is incorrect: it requires either the pg_execute_server_program role or superuser)
While this is not a vulnerability in PostgreSQL, it is certainly a vulnerability present in a non-trivial number of installations of PostgreSQL deployments. The solution to that vulnerability is to not grant superuser permissions to user, and a common setup is to only allow the postgres OS user itself to act as superuser, in which case there is no escalation at all. Unfortunately, the "vulnerability" blog post doesn't mention anything at all about this.
It seems PostgreSQL needs some better documentation about this for new users, possibly along the CREATE ROLE page which does not explicitly mention this. But if superuser is granted to a user, that remains the equivalent of granting the OS user permissions.
We can certainly discuss if it's user friendly to allow such functionality, but the system is operating exactly as intended, and it's not a vulnerability.
If you have any application that uses superuser, you should fix that right away. And if you care about your security at all, you should definitely make sure to use pg_hba.conf to ensure that no superuser can log in to the system remotely.
As a footnote, the PostgreSQL Security Team was contacted by Trustwave, warning us about the upcoming blogpost. We explained in our response that this is not considered a vulnerability, since it's the product working as intended. We do not know why they proceeded to register a CVE entry regardless of that.
Comments
Add comment
New comments can no longer be posted on this entry.