Because of ubiquity of cloud if a customer/user of a client service - in this case an Oracle database - can find a way to get to the container / hypervisor / CDB in this case then that is dangerous as a customer could access the root layer or another customers database. One type of attack that could occur is a denial of service; where all customers are denied access to their database and in this case the root container also.
Emad discusses the fact Lockdown profiles are used to enforce some of the security between the root container and the pluggable database. In the demo by Emad he shows that whilst OS_ACCESS was in place to restrict OS access he was able to disrupt the root container and whole database. Emad shows how he OS_ACCESS worked for one user and blocked granting permissions on a DIRECTORY object that was created. This stopped the exploit BUT he then creates another user that uses DBMS_BACKUP_RESTORE.DELETE_FILE to delete the spfile from the database stopping it to start up.
Oracle fixed this bug in the October 2023 CPU
I want to discuss this further. I have always taught about file system access and the dangers in my 3 day Oracle security class. The wisdom from CIS was to unset utl_file_dir if it was set to a dangerous location (gone now) and to block EXECUTE on UTL_FILE but there is a big problem with this. UTL_FILE is used in many other places in the Oracle code and some of those places are also granted EXECUTE to PUBLIC.
SQL> col name for a30
SQL> col owner for a30
SQL> col type for a30
SQL> set lines 220
SQL> @dep_priv
Enter value for object_to_test: UTL_FILE
old 3: where referenced_name='&&object_to_test'
new 3: where referenced_name='UTL_FILE'
Enter value for owner_to_test: SYS
old 4: and referenced_owner='&&owner_to_test'
new 4: and referenced_owner='SYS'
NAME OWNER TYPE
------------------------------ ------------------------------ ------------------------------
DBMS_SCHEDULER SYS PACKAGE BODY
UTL_FILE SYS PACKAGE BODY
DBMS_ADVISOR SYS PACKAGE BODY
DBMS_AW_EXP SYS PACKAGE BODY
DBMS_CUBE SYS PACKAGE BODY
DBMS_METADATA SYS PACKAGE BODY
KUPW$WORKER SYS PACKAGE BODY
KUPM$MCP SYS PACKAGE BODY
KUPF$FILE SYS PACKAGE BODY
9 rows selected.
SQL>
So even if we revoke the PUBLIC EXECUTE from UTL_FILE we also should look at these above as they also have grants of EXECUTE to PUBLIC and then for each of these check if they also have grants of EXECUTE to PUBLIC ad-infinitum.
Also this is just PUBLIC grants; but if an attacker has access to other schemas such as defaults then these could also have access to UTL_FILE directly or via other packages. So we should consider all grantees and not just PUBLIC.
There are also other PL/SQL packages that access the file system that perhaps do not use UTL_FILE. We will see more on this in a minute.
OK, that is packages using UTL_FILE. The second way Oracle allows access to the file system is via Java:
SQL> @java_file
G_R PERM GRANTEE PERMNAME ACTION
--- --------------- ---------- ---------------------------------------- ----------
G FilePermission JAVASYSPRI [[ALL FILES]] read,write
G FilePermission JAVAUSERPR [[ALL FILES]] read
G FilePermission JMXSERVER javavm/lib/management/* read
G FilePermission JMXSERVER javavm/lib/management/jmxremote.access read
G FilePermission JMXSERVER javavm/lib/management/management.propert read
G FilePermission MDSYS md/jlib/* read
G FilePermission MDSYS md\jlib\* read
G FilePermission MDSYS sdo/demo/georaster/jlibs/* read
G FilePermission MDSYS sdo\demo\georaster\jlibs\* read
G FilePermission SYSTEM [[ALL FILES]] read
10 rows selected.
SQL>
These default Java VM permissions that relate to file access are included by default. Oracle also write packages that use Java or a user could utilise a Java VM permission in the database to write Java or PL/SQL that uses Java to access the file system. Finding these packages are harder.
The third category after access via utl_file_dir / DIRECTORY objects via packages such as UTL_FILE and Java are packages that use direct C libraries to access the file system such as DBMS_BACKUP_RESTORE. I covered the access to this package in check 3.1.2 in the SANS Oracle Security Step By Step Guide back in 2002/2003. This is a dangerous package and it uses C to access the file system.
Because the SANS book was donated by SANS before publication to CIS for the Oracle Security Benchmark first version then this package access was also included that check list.
So there are three main ways to access the file system from PL/SQL
- Via PL/SQL packages that use utl_file_dir (earlier) and DIRECTORY objects
- Via the Java file permissions in the Java VM used direct or via Java or Java and PL/SQL
- Packages that use C libraries such as DBMS_BACKUP_RESTORE
The next step in understanding the size of the problem is to search Oracle packages that might do something with files:
SQL> col owner for a30
SQL> col object_name for a30
SQL> col procedure_name for a30
SQL> l
1 select owner,object_name,procedure_name
2 from dba_procedures
3 where object_name like '%FILE%' or procedure_name like '%FILE%'
4* order by 1,2,3
SQL> /
OWNER OBJECT_NAME PROCEDURE_NAME
------------------------------ ------------------------------ ------------------------------
AUDSYS DBMS_AUDIT_MGMT LOAD_UNIFIED_AUDIT_FILES
CTXSYS CTX_OUTPUT LOGFILENAME
CTXSYS CTX_OUTPUT LOGFILEOVERWRITE
CTXSYS DRVIMR DIRECT_GET_BFILE
DVSYS DBMS_MACADM CHECK_DB_FILE_PARM_VARCHAR
DVSYS DBMS_MACOLS_SESSION SET_ACCESS_PROFILE
GSMADMIN_INTERNAL DBMS_GSM_POOLADMIN ADDFILE
GSMADMIN_INTERNAL DBMS_GSM_POOLADMIN MODIFYFILE
GSMADMIN_INTERNAL DBMS_GSM_POOLADMIN REMOVEFILE
GSMADMIN_INTERNAL DBMS_GSM_POOLADMIN RETRIEVEFILE
...
XDB DBMS_XDB_CONTENT CREATEFILE
XDB DBMS_XDB_CONTENT CREATEFILE2
XDB DBMS_XDB_CONTENT CREATEFILE3
XDB DBMS_XDB_CONTENT DELETEFILE
XDB DBMS_XMLDOM SETNODEVALUEASDEFERREDBFILE
XDB DBMS_XMLDOM WRITETOFILE
XDB DBMS_XMLDOM WRITETOFILE
XDB DBMS_XMLDOM WRITETOFILE
XDB DBMS_XMLDOM WRITETOFILE
XDB DBMS_XMLDOM WRITETOFILE
XDB DBMS_XMLDOM WRITETOFILE
XDB DBMS_XMLDOM WRITETOFILE
OWNER OBJECT_NAME PROCEDURE_NAME
------------------------------ ------------------------------ ------------------------------
XDB DBMS_XMLDOM WRITETOFILE
XDB DBMS_XSLPROCESSOR CLOB2FILE
801 rows selected.
SQL>
There are some that are not files as the SQL was not very clever, i.e. it found some with %PROFILE%. That is OK, we see over 800 rows of potential PL/SQL in the database that does something with files.
We could go much further and write a better query that also takes into consideration parameters that clearly do something with a file but the package name and procedure name do not give this away. I will not do this now.
So, the problem is that the database exposes so much file system activity possibilities but hardening guides recommend revoking PUBLIC EXECUTE from UTL_FILE and DBMS_BACKUP_RESTORE but access to this package is not available by default to PUBLIC.
If we revoked grants on these it would not secure the database as we would need to revoke grants on all packages that use these packages and the packages that use those ad-infinitum as well as locating all of the packages above and revoking them and all the callers as well.
Clearly this is nonsense and we cannot do this.
I have outlined this in my training classes for years and the only obvious solution is to focus on the DIRECTORY objects; do not allow them to be created, check the Oracle defaults and also check existing customer ones. If you have an old database also check utl_file_dir and then review all Java File VM permissions and Oracle roles and users that are granted them; remove and do not allow more to be granted. There is no solution to C based packages except to ensure they are not granted to anyone.
This is a massive task and why lock down profiles OS_ACCESS is great as it clearly blocks the low level as I have been saying for years but there was a gap.
Even if you set up lock down profiles and OS_ACCESS I would also control DIRECTORIES and permission and Java
#oracleace #sym_42 #oracle #database #security #dos #hacking #file #directory #java
