Security researchers have warned that a "feature" of PostgreSQL could allow certain database users to gain arbitrary code execution in the context of the user running the Postgres instance.
According to a blog post by security researcher Jacob Wilkin at Trustwave, the issue is enabled by default on all versions of PostgreSQL from 9.3 through to the latest of 11.2. It also affects all operating systems, Windows, Linux and Mac.
"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," said Wilkin.
He added that such a problem was something seen in Microsoft SQL Server back in the early 2000s when the xp_cmdshell function was enabled by default.
"This was patched and disabled by default in Microsoft SQL Server 2005, but it is interesting how the same bugs repeat, seemingly in cycles," said Wilkin.
Wilkin said that the bug is somewhere between a privilege escalation and an arbitrary code execution and needs some prior authentication.
"This is achieved either through access to the database with credentials or via exploiting an SQL injection in an application which has PostgreSQL on the backend. Again, in both of these instances, either the superuser or a user with ‘pg_read_server_files’ permissions need to be in use," said Wilkin.
Wilkin said that while the feature is documented, it creates a security problem.
"xp_cmdshell is disabled for a reason. I understand that Postgres might want to keep the feature, however I believe it should not be enabled by default," he added in a comment on his personal blog.
Pascal Geenens, security evangelist for Radware, told SC Media UK that this could be used as a privilege escalation if the pgSQL server is running as privileged user.
"It does require a valid pgSQL user with enough rights to be able to perform the escalation. I would suggest DB administrators to limit the users in ‘pg_read_server_files’ and ensure good password hygiene for privileged user accounts," he said.
He added that if an attacker is able to get access to a database with a privileged user, there are much worst scenario’s that one could imagine, such as deleting all tables and putting a Ransom on the database owners, extracting private information and ransom or sell on the dark web or go in and make some subtle changes that to the data that might impact the applications in many different ways, crippling or hurting the companies reputation or processes.
"The abuse of privileged access would very much depend on the type of attacker and his objectives, this particular vulnerability could be of most interest to hacking groups that are infiltrating and in the game for the long run for surveillance or information gathering, like nation state sponsored groups," he said.
Paul Ducklin, senior technologist at Sophos, told SC Media UK that the good news here is that this isn't a vulnerability that just anyone can trigger from anywhere.
"The flaw is accessible only to users who are in the special PostgreSQL group 'pg_read_server_files'. So, there's a workaround, namely to scale back the number of users to whom you grant the 'pg_read_server_files' permission," he said.
"Although the name of this user group doesn't explicitly say '_and_run_programs_too', the Postgres manual makes it clear that users in this group can 'bypass all database-level permission checks when accessing files directly' and that and thus could be 'used to gain superuser-level access'. If you're a PostgreSQL user, use this issue as a reason to revisit which users you've let into what groups, and bear in mind that the division between admin level and non-admin level may not be quite as clear-cut as you first thought."