Hi team,

I am leading PCI:SSF audit on our payment switch platform product and having a 
issue where our QSA just came with multiple ways how to escalate privileges and 
get a shell to the remote host through our built-in Reporting system which runs 
on PostgreSQL (12-14).

  1.  select * from pg_read_file('/etc/passwd' , 0 , 1000000); -> it's possible 
to display content of '/etc/passwd/' file
  2.  select version(); -> Result of DBMS version request.
  3.  COPY (SELECT 'nc -lvvp 2346 -e /bin/bash') TO '/tmp/pentestlab'; -> it's 
possible to create files on the filesystem on behalf of 'postgres' user.

The main problem comes from obvious - our application's PostgreSQL user needs 
to have an Superuser role as it manages most of its (dedicated) database 
(creates tables, drops those, manages views, triggers ... ).

This all matches description from documentation as follows:

<https://www.postgresql.org/docs/14/predefined-roles.html><https://www.postgresql.org/docs/14/predefined-roles.html>

The pg_read_server_files, pg_write_server_files and pg_execute_server_program 
roles are intended to allow administrators to have trusted, but non-superuser, 
roles which are able to access files and run programs on the database server as 
the user the database runs as. As these roles are able to access any file on 
the server file system, they bypass all database-level permission checks when 
accessing files directly and they could be used to gain superuser-level access, 
therefore great care should be taken when granting these roles to users.

</>

So these - pg_read_server_files, pg_write_server_files and 
pg_execute_server_program roles are inherited from the Superuser and are also 
super sensitive for us, but our application user apparently still needs to be 
superuser for multiple reasons. Would there be any way to go around this?

1/ What we need is to create a postgresql user who would be pg_database_owner 
but not superuser ... but apparently we still need our user to be superuser to 
be able to carry on with some operations (picking one of more then few) ....

CREATE OR REPLACE LANGUAGE plpython3u;
HINT:  Must be superuser to create this extension.

2/ Second option is to introduce some sort of limitation of allowed SQL queries 
and operators for our Reporting engine, but all that white-listing / 
blacklisting comes with its own problems where we are DB agnostic...

I am sorry for a long email, but any ideas/pointers will be greatly appreciated.

Thank you & Kind Regards,
Jan

--
Jan Bilek - CTO at EFTlab Pty Ltd.

Reply via email to